Originariamente inviato da TrueLies
Grazie a chi vorrà rispondere (peccato non è oggetto di scommesse alla lottomatica!)
ciau
Che ci vuoi fare, intervieni alle discussioni a cui sono iscritto io. Anche se non guardassi il forum mi arriverebbe comunque una notifica via email

Originariamente inviato da TrueLies
Scusatemi, ma date le diverse opzioni (da che programmazione è programmazione, c'è sempre più di un modo di fare le cose) perchè non analizzare quale soluzione è migliore anzichè presentarle come indiscriminatamente equivalenti?
Nessuno ha mai detto che sono equivalenti.

Originariamente inviato da TrueLies
Ora: il metodo tradizionale funziona su qualsiasi browser dell' universo usato da esseri umani.

A tal punto, questa considerazione dovrebbe già essere sufficiente a dirci che è quello l'approccio procedurale da usare.
Cosa intendi per "metodo tradizionale"?

Originariamente inviato da TrueLies
Non si capisce infatti perchè in un caso del genere si dovrebbe usare setUserData: quello che dobiamo assegnare è un valore stringa -e qui già uno dei "vantaggi" di setUserData si perde del tutto; poi dobbiamo settare un id, proprietà invero spesso assai fondamentale per uso DOM, per cui per quale motivo utilizzare setUserData il quale ha lo scopo di non coinvolgere direttamente il DOM -si perde un secondo "vantaggio" di setUserData.

A questo punto, perchè proporlo? Cioè, magari c'è un motivo assolutamente fondamentale per cui in questo caso sarebbe consigliabile usarlo ma a me sfugge e allora spiegatemelo. Ma se il motivo non c'è, allora spieghiamo anche quale è l'uso appropriato di setUserData anzichè impiegarlo solo perchè si può.
Perché ci sono casi in cui gli Id sono già "occupati" per altri usi o perché non dobbiamo salvare solo un'informazione, ma molte informazioni, o semplicemente perché è molto meno dispendioso leggere un booleano che convertire una stringa in booleano con Boolean("[STRINGA VUOTA/OPPURE NO]"). Ripeto, è una proprietà che è stata inventata apposta per questi usi.

Originariamente inviato da TrueLies
Quanto all' operatore let, il suo unico vantaggio è di permettere una inzializzazione in uno scope volatile. Nel contesto in cui è inserito qui, o espleta lo stesso ruolo che impiegare var, o contamina comunque lo scope della window.
È vero che tra i tre è il metodo più dispendioso (si crea uno scope per ogni ciclo – ma attenzione! uno scope non è una closure, è qualcosa in meno in termini di dispendio di risorse!). Ma non espleta lo stesso ruolo che espleterebbe var. Con var semplicemente non funzionerebbe.

Originariamente inviato da TrueLies
Cioè: se i vantaggi nel caso specifico non ci sono, perchè non andare direttamente al metodo standard anzichè impiegare caratteristiche nuove pensate per scopi e finalità molto specifiche e limitate e che dunque sarebbe più sensato riservare a quei casi - o si smarrisce completamente il senso delle cose.
Quale sarebbe il metodo standard, quello delle closures??

Originariamente inviato da TrueLies
Per carità, io non ho nulla in contrario ad usare una sintassi perchè magari ci piace di più e farne una questione di programmazione estetica - è che siccome sono abituato a programmare in modo diverso, cioè ad usare le cose quando servono (e anche lì siccome siamo umani è sempre possibile sbagliare), mi chiedevo se magari vi era in questo contesto un qualcosa che mi sfugge alla luce del quale invece l'uso delle alternative si fa non solo pertinente ma necessario e funzionalizzato agli scopi per soddisfare i quali le alternative sono nate.
Continui a parlare di estetica, ma ti assicuro che passo molto tempo a esaminare la performatività e il dispendio di memoria delle tante risorse che offre javascript.