ok lo ammetto sono niubbo, mi affido al DS

ah ma non è che più parole ci sono meglio è? 

magari con android non c'è niente da "implementare"

 

 

l'ho già spiegato over9000 volte, se voleva imparare imparava

Ma con tutti i soldi che investono in puttanate possibile che google/crapple/ms (credo, mai provato) non riescono a tirar su dei framework decenti?

Cristo android fa sembrare java un linguaggio di merda, per non parlare di quella pena stitica dell'objective c

 

beh swift è carino

va caca:

C#
Var names = { "Sam", "Pamela", "Dave", "Pascal", "Erik" }.Where((c, index) => c.Length <= index + 1).

Java streams
String[] names = {"Sam","Pamela", "Dave", "Pascal", "Erik"};
OfInt indices = IntStream.range(1, names.length).iterator();
List<String> nameList = stream(names).map(c -> Pair.of(indices.next(), c))
                                      .filter(c -> c.getValue().length() <= c.getKey())
                                      .map(Pair::getValue)
                                      .collect(toList());

anche un coglione come te dovrebbe capire che non c'è paragone tra quella merda di Java e c#.

 

 

la cosa più sfigata è che una volta che "enumeri" (il collect finale) ti sei giocato lo stream/albero funzionale/chiamalo come vuoi

 

 

ai tempi (boh, l'anno scorso) avevo letto che non potevano farlo linq-like per via di brevetti MS

ah, sono talmente abituato a linq che ormai anche in qualsiasi cosetta js che faccio uso librerie tipo underscore js per i vari map, reduce, blabla

 

 

 

e scrivo tutto il js in typescript anche solo per avere la notazione "(a, b) =>  cose" al posto di function(a, b){cose;}

Edited by toyo, 07 March 2015 - 20:48.

la cosa più sfigata è che una volta che "enumeri" (il collect finale) ti sei giocato lo stream/albero funzionale/chiamalo come vuoi


ai tempi (boh, l'anno scorso) avevo letto che non potevano farlo linq-like per via di brevetti MS

non credo sia questione di brevetti, il problema principale è la mancanza di extension methods e la volontà di non cambiare la loro virtual machine OBSOLETA. (Che, ricordo, implementa i generics tramite type-erasure, cosa che mi fa letteralmente andare in bestia)
Ecco un esempio di un errore lanciato quando qualcosa va male durante una semplice select:

Stream lengths = names.stream().map(name -> check(name)); at LmbdaMain.check(LmbdaMain.java:19)at LmbdaMain.lambda$0(LmbdaMain.java:37)at LmbdaMain$$Lambda$1/821270929.apply(Unknown Source)at java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:193)at java.util.Spliterators$ArraySpliterator.forEachRemaining(Spliterators.java:948)at java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:512)at java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:502)at java.util.stream.ReduceOps$ReduceOp.evaluateSequential(ReduceOps.java:708)at java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234)at java.util.stream.LongPipeline.reduce(LongPipeline.java:438)at java.util.stream.LongPipeline.sum(LongPipeline.java:396)at java.util.stream.ReferencePipeline.count(ReferencePipeline.java:526)at LmbdaMain.main(LmbdaMain.java:39)

Porco dio, bisogna essere davvero dementi per sottoporsi a questa tortura nel 2015, quando è dal 2007 che in c# le cose sono fatte decisamente meglio, e 'sti cazzoni hanno avuto ben SEI ANNI E MEZZO in più e hanno partorito questa CAGATA GALATTICA.

Edited by TigerShark, 08 March 2015 - 09:52.

non credo sia questione di brevetti

 

 

"linq patents" su google, primo risultato: http://www.google.co...s/US20100114885

"linq patents" su google, primo risultato: http://www.google.co...s/US20100114885

tutti i linguaggi decenti hanno le funzioni di map/reduce &co. implementate correttamente, ergo NON è questione di brevetti.
È proprio l'implementazione Java che fa cagare a spruzzo.

si ok leggendolo il brevetto è legato più a linq to sql che a linq

 

 

btw M$ quella volta per far funzionare bene linq si è inventata un sacco di cosine nuove nel linguaggio, tipo l'inferenza dei tipi con var, gli extension method, gli anonymous types ( e il loro utilizzo con var), blabla, brava dai

 

 

 

 

btw, a l'hondon che usate? query sintax o fluent sintax?

 

 

io sono all in per la fluent, mi è capitato di usare la query solo quando avevo datasource multipli ("join" che non erano mappate su EF) e/o quando mi fa comodo usare il "let"

 

 

ma > 90% fluent ad occhio

Edited by toyo, 08 March 2015 - 10:19.

anche perché la query sintax è un pugno in un occhio dai

Proof:

Map[String, Int] = a.map(i => (i, f(i)))(scala.collection.breakOut)

si ok leggendolo il brevetto è legato più a linq to sql che a linq
 
 
btw M$ quella volta per far funzionare bene linq si è inventata un sacco di cosine nuove nel linguaggio, tipo l'inferenza dei tipi con var, gli extension method, gli anonymous types ( e il loro utilizzo con var), blabla, brava dai
 
 
 
 
btw, a l'hondon che usate? query sintax o fluent sintax?
 
 
io sono all in per la fluent, mi è capitato di usare la query solo quando avevo datasource multipli ("join" che non erano mappate su EF) e/o quando mi fa comodo usare il "let"
 
 
ma > 90% fluent ad occhio

fluent, anche quando ho bisogno di let in caso aggiungo un code block per definire una variabile temporanea o aggiungo prima una select, anche se di solito se hai bisogno di una let è un code smell che indica che probabilmente puoi cambiare il tuo object model per semplificarlo.
Anche quando devo fare join di solito uso sempre la fluent iterando su due sequenze o mappandole in un dictionary per migliorare le performance.

Roba da nerd segaioli 

Anche quando devo fare join di solito uso sempre la fluent iterando su due sequenze o mappandole in un dictionary per migliorare le performance.

 

pa?

 

fammi un esempio, facciamo finta di avere un IEnumerable<A> foo e un IEnumerable<B> bar

Tra l'altro dio cane se proprio si vuole usare la jvm almeno che si usi scala che è over 9000 volte meglio di Java.
Ma il 90% dei fottuti programmatori sono così closed-minded che una volta che imparano un linguaggio si fossilizzano su quello anziché spaziare e vedere cosa offrono le altre tecnologie.
Infatti non farei mai definire architetture intere a BESTIE del genere.

il "pa" è relativo al "mappandole in un dictionary per migliorare le performance"

 

e si, so come funziona un dictionary e la performance asintotica delle varie operazioni

pa?

fammi un esempio, facciamo finta di avere un IEnumerable<A> foo e un IEnumerable<B> bar

foos.Where(f => bars.Contains(f.barId));

Ovviamente le performance fanno cagare visto che è o(m x n) quindi di solito ci aggiungo una Collection temporanea con un semplice ToDictionary e in quel modo il lookup è o(1).

EDIT: visto altro messaggio:

var tempBars = bars.ToDictionary(k => k.barId, k => k);

Ovviamente se l'id non è unique uso il comodissimo ToLookup.
E ovviamente si può eliminare la variabile temporanea inserendo il ToDictionary direttamente nel linq statement.

Edited by TigerShark, 08 March 2015 - 10:47.

ah k capito

 

anche se intendevi più un

foos.Where(f => bars.Select(bar => bar.Id).Contains(f.barId));

che altrimenti non ti compila

ah k capito
 
anche se intendevi più un

foos.Where(f => bars.Select(bar => bar.Id).Contains(f.barId));

che altrimenti non ti compila

ho scritto a cazzo sull'ipad comunque non serve la select:

foos.Where(f => bars.Any(b => f.BarId);

poi quel tempBars lo usi per fare il contains giusto? fai na roba tipo tempBars.Keys.Contains o un tryget?