2015-02-27 10:17 GMT+00:00 Carlos Catucci <carlos.catu...@gmail.com>:
> > La const in se fa comodo ma si vive anche senza (per convenzione io uso > una var maiuscola e so che e' una costante per cui non la cambio mai, > inoltre uso i namespaces, quindi mi basta uno chiamato CONST seguito da > .nomecostante e evito il problema. > A me const piace. Personalmente il fatto che in Python tutti i modi per rendere qualcosa immutabile (almeno rispetto a cambiamenti accidentali) siano lunghi dispiace. Di fatto l'unico modo di avere qualcosa di *veramente* immutabile in pure Python e' fare information hiding con delle chiusure lessicali (sempre a meno che qualcuno non si metta a smacchinare con i frame a mano... ma bisogna un po' cercarsela, ecco) e l'altro modo e' usare delle property... Ovviamente dal punto di vista del compilatore non ci sono garanzie a sufficienza per fare le ottimizzazioni che si potrebbero fare altrimenti e dal punto di vista dell'utente va bene (ed e' comodo) solo se appunto si sta lavorando con degli oggetti. Fosse per me, tutti gli assegnamenti dovrebbero essere const "salvo istruzione contraria". Riguardo al const di Javascript non mi e' chiaro -- dovrei leggere la specifica -- se si riferisce al binding o anche all'oggetto... ma per come funziona Javascript credo la prima. > Destructuring non e' male forse, ma mi sembra un poco contorto, in fondo > e' un array no? > Destructuring mi sembra abbastanza analogo al pattern matching, che e' una cosa *comodissima* in vaste classi di linguaggi (Scala, Haskell, ML). Ovviamente la versione di Javascript e' pesantemente unsafe e non sono particolarmente convinto che semplifichi la vita. Il giochetto poi dei valori "skippati" fatto con le virgole mi sembra veramente un'idea che poteva venire in mente a Lerdorf. Spread e' un passare una lista come parametro ad una funzione che si > aspetta una serie di parametri. Avrei preferito una evolusione del tipo > *args,**kwargs alla Python. > Sintassi. Sono con te sul fatto che quella di Python sia piu' bella, ma alla fine ... viene usato con un significato simile in Java, C++, C e Go (e suppongo anche altri) e penso che abbia senso per JS andare avanti cosi', visto che tanto la cagata di prendere un linguaggio bellino e rovinarlo con features e sintassi che non hanno nulla a che vedere venne fatta fin dall'inizio. > Arrow function mi fa tanto PHP, e non ho capito come funziona. Il tipo fa > prima un esempio dove scrive > > employees.forEach(function(emp) { > totalAge += emp.age; > }); > > E va bene, ma qui emp la definisce lui come parametro passato alla > funzione, poi scrive > > employees.forEach(emp => { > totalAge += emp.age; > }); > > che sarebbe la lambda, ma scritto cosi' e' poco chiaro. Questioone di > leggibilita', tutto qui. > Non vedo perche' PHP. Ok, forse -> era piu' chiaro (come fanno in C++, Java e Scala; e tanti altri). Non e' che => invece di -> mi cambi la vita. Poi il fatto e' che mi fa molto dispiacere come le persone non comprendano la bellezza del paradigma funzionale, ne prendano dei pezzi e proseguono a scrivere codice imperativo, con tutte le eventuali complicazioni di mappare concetti funzionali nel mondo imperativo e tutti gli svantaggi logici ed effettivi del mondo imperativo. Cioe'... capirei un esempio del tipo employees.sum(emp => emp.age) o qualcosa di simile... Ma prendere una variabile e mutarla e' una cosa cosi' brutta... ti spacca un'eventuale auto-parallelizzazione (che vabbe', in Javascript non si potrebbe fare visto la semantica dei numeri). Ti incasina un sacco di cose quando vuoi usare veramente higher order functions... ma voglio dire... Vabbe'... Non ho ancora visto bene il resto, gli iterators forse sono una cosa buona, > idem per i generators, ma devo ancora darci un'occhio bene. > Ma si... alla fine e' quasi tutto sensato. Diciamo che cosi' Javascript non sembra essersi perso 20 anni di evoluzione dei linguaggi. La parte che mi fa paura sono le classi. Cioe'... Gia' per fare OOP in Javascript c'erano tipo 3-4 modi diversi, ci mancava proprio il 5o. E poi voglio vedere come mappano il modello di OO tradizionale con quello a prototipi in modo che tutto funzioni senza sorprese (io ho idea che ci sara' un altro manualetto di 200 pagine con tutti i gotcha su come le due cose interagiscono). -- . ..: -enrico-
_______________________________________________ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python