Ciao Google Analytics usa la struttura riportata in oggetto. Quale motivo tecnico c'è?
cosa significa: ()() ?
se scrivo (function(){alert(1)})(alert(2)); vedo il 2 e poi 1
Ciao Google Analytics usa la struttura riportata in oggetto. Quale motivo tecnico c'è?
cosa significa: ()() ?
se scrivo (function(){alert(1)})(alert(2)); vedo il 2 e poi 1
Farmacia di Jarno - le mie pillole: Cookie [#780810], Dom4Php4 [#1123236], Fade [#1139489], getCssProperty [#1152911]
Inchinatevi difronte al Prof! Nacchio!
A me pare che l'uomo vada avanti con la retromarcia
()() non significa niente se la prima parentesi non contiene una funzione. Scrivere:
è la stessa cosa che scrivere:codice:(function(){alert(1)})(alert(2));
e di conseguenza:codice:var miaFunzione = function(){alert(1)}; (miaFunzione)(alert(2));
Ora è più chiaro?codice:var miaFunzione = function(){alert(1)}; miaFunzione(alert(2));
Ciao,
grazie della spiegazione.... a questo punto non capisco il perchè di tali costruzioni...
Farmacia di Jarno - le mie pillole: Cookie [#780810], Dom4Php4 [#1123236], Fade [#1139489], getCssProperty [#1152911]
Inchinatevi difronte al Prof! Nacchio!
A me pare che l'uomo vada avanti con la retromarcia
Sono utilissime perché consentono di eseguire delle funzioni una volta sola (tali funzioni sono dette funzioni lambda). Ti faccio un esempio. Il codice seguente estrae tutte le variabili contenute nell'indirizzo della pagina dopo il punto interrogativo (es. http://www.tuoindirizzo.it/tuapagina.html?miaVariabile=contenuto&ciao=mondo) e le annida come chiavi di un oggetto globale di nome oGetVars. Non volendo dichiarare nessun'altra variabile globale (né funzione) oltre a oGetVars, il codice non potrebbe essere scritto altrimenti:
codice:var oGetVars = new (function(sSearchStr) { function buildValue(sValue) { if (/^\s*$/.test(sValue)) { return(null); } if (/^(true|false)$/i.test(sValue)) { return(sValue.toLowerCase() === "true"); } if (isFinite(sValue)) { return(parseFloat(sValue)); } if (isFinite(Date.parse(sValue))) { return(new Date(sValue)); } return(sValue); } if (sSearchStr.length > 1) { var iCouple, aCouples = sSearchStr.substr(1).split("&"); for (var iCouplId = 0; iCouplId < aCouples.length; iCouplId++) { iCouple = aCouples[iCouplId].split("="); this[unescape(iCouple[0])] = iCouple.length > 1 ? buildValue(unescape(iCouple[1])) : null; } } })(window.location.search); // alert(oGetVars.ciao); // oppure // alert(oGetVars.miaVariabile);
A parte i copia e incolla da mozilla, si tratta di variazioni sulle cosiddette enclosures. In realtà, non hai molti motivi per utilizzare questo tipo di espressioni, o perlomeno non sono pensate per evitare l' "inquinamento" degli spazi globali (anche se puoi utilizzarle a tale scopo, ma ha poco senso: uno sviluppatore conosce il suo ambiente di produzione e sa quali variabili o strutture dati vi operano).
Ad una variabile puoi assegnare come valore una funzione:
var foo=function(arg){alert(arg);}
ora, chiaramente:
foo('ciao'); chiama la funzione e lancia l'alert.
La sopravvivenza del valore passato all' argomento (nel nostro caso 'ciao') tuttavia non è sempre certa.
Se ad esempio l'argomento di foo fosse una risposta ajax (interroghi il server con ajax, e la tua funzione rimane in ascolto della risposta del server) un sintassi del tipo
var foo=function(risposta){alert(risposta);}
non funzionerebbe: siccome il server risponde dopo un certo tempo (magari mezzo secondo, ma comunque NON subito, non istantaneamente), ma la funzione è eseguita subito, si smarrisce la possibilità di assegnare il valore che a 'risposta' darà il server: la funzione si esegue SUBITO ma il server fornirà il valore di 'risposta' PIU' TARDI.
Una espressione invece del tipo:
var foo=function(risposta){function(){alert(risposta)} }
che incapsula una funzione dentro una funzione, consente la sopravvivenza del namespace (ed è questo il namespace che di solito si vuole preservare - quello asincrono non quello dell' oggetto window).
Siamo nell' ambito del
currying e del lambda: sono trucchetti usati o per garantire la sopravvivenza degli argomenti di una funzione in un ambiente dove tale sopravvivenza non è certa, o per passare funzioni come argomenti di altre funzioni.
Non ti preoccupare del gran mal di testa: è uno di quegli argomenti che devi sfruttare così: archivi la sua esistenza, poi quando un giorno ti troverai innanzi alla necessità in un tuo codice di fare sopravvivere un argomento di funzione o di passare una funzione come argomento ad una altra e troverai delle difficoltà, ti ricorderai di questo argomento e sarà allora, applicandolo ai tuoi codici, che lo capirai meglio.
Quanto a capirlo completamente, no non accadrà: per quale motivo questo incapsulamento esita in questo tipo di comportamento infatti deriva solo dalla maniera in cui è stato progettato l'interprete javascript e non da alcuna virtù misteriosofica delle espressioni lambda che si autoimporrebbe a javascript: javascript si comporta a questo modo perchè degli essere umani lo hanno istruito a comportarsi in questo modo - è una convenzione, non una forza della natura che si rivela.
Ah scusa, per completezza di discorso e per verificare come spesso si faccia uso di enclosures senza che ve ne sia alcun motivo reale (per questo sottolineavo che la funzioni in currying o lambda ha senso usarle quando serve, e non solo perchè lo si può: è inutile sparare ai canarini con i carri armati):
se tu hai una pagina con una query, che so:
nomepagina.php?yourVar=2&pippo=ciao it's good to see you
La struttura dati minimale:
var getVars={
'foo': function(){ var s=window.location.search.substring(1).split('&'); for(var i in s){this[s[i].substring(0, s[i].indexOf('='))]=unescape( s[i].substring(s[i].indexOf('=')+1) );} return this;}
};
alert(getVars.foo().pippo);
alert(getVars.foo().yourVar);
ti esegue quanto desiderato, cioè ottenere un oggetto dove siano raccolte come proprietà gli elementi della query, in maniera semplicissima e più leggibile. (meglio ancora sarebbe non mettere il return this e invocare una volta sola foo(), in maniera da non ripopolare, e poi invocatolo una volta sai che disponi delle proprietà: semplice e diretto allo scopo, e senza inquinare alcun namespace che non sia quello già impiegato di getVars).
Poi puoi aggiungerci qualche dettaglio ma quello che mi preme sottolineare è che il fatto che tu veda su megasiti come Google o come Mozilla delle implementazioni barocche (il loro scopo di solito è meramente didattico: non ti suggeriscono che tu debba fare così, ma solo ti segnalano una prassi possibile: sta a te capire che l'intento didattico non coincide con l'incoraggiamento ad applicare la soluzione indiscriminatamente), non deve indurti a pensare che quelle implementazioni siano necessarie: come Feyerabend disse una volta, il fatto che sotto una soluzione inutile siano collezionate delle firme scientifiche autorevoli non rende la soluzione più utile ma la rende solo "una enciclica scientifica".
Non perdere quindi il capo su quel che fa Google (che magari avrà i suoi motivi per fare le cose, ma il loro 'backstage' non ci è giustamente noto, o magari non li avrà): archivia il fatto che il currying e le espressioni lambda sono possibili, e poi usale quando ti accorgerai che davvero possono servirti e risolverti un problema, non iniziare ad usarle solo perchè si può o perchè rende il tuo codice più "cool" a vedersi
O, almeno, io ti suggerisco di imparare a programmare così: in maniera funzionale, e non estetica, mettendo nella tua faretra le soluzioni che oggi non ti servono per quando ti accorgerai che ti servono.
Poi, beninteso, liberissimo di seguire altri approcci meno orientati all' obbiettivo pratico. Nulla in contrario.
Oh, prima della pausa pranzo
Allora tu hai:
var getVars={
'foo': function(){ var s=window.location.search.substring(1).split('&'); for(var i in s){this[s[i].substring(0, s[i].indexOf('='))]=unescape( s[i].substring(s[i].indexOf('=')+1) );} return this;}
};
getVars.foo();
alert(getVars.pippo);
alert(getVars.yourVar);
Siccome hai il controllo del tuo ambiente di sviluppo, sai che cosa contiene getVars e sai che le tue query non hanno un parametro foo: se lo avessero, sovrascriverebbe la proprietà funzione. In realtà il danno non ci sarebbe nemmeno se venisse manualmente aggiunto: la tua procedura si ferma, e il db non è invocato (i tuoi script php devono tutti controllare che i dati siano quelli attesi, con i name dei parametri attesi, e se c'è qualcosa di diverso, devono abortire: la vera sicurezza non è mai dal lato client - ingenerare la illusione che possa esserlo è pericolosissimo). Questo senza contare che basterebbe una modifica minimale al codice per ovviare anche a questa situazione:
if(s[i].substring(0, s[i].indexOf('='))=='foo'){continue;};/*no no: io controllo il mio ambiente: perchè stai provando a mettere roba che non ci deve stare... anzi sai che... a questo punto... non ti ci voglio proprio qui e anzi MOLTO BENE che me ne sia accorto che ci hai messo roba di tuo...*/
if(s[i].substring(0, s[i].indexOf('='))=='foo'){location.href='http://www.fbi.gov'; return;};
La idea di mozilla di incapsulare e proporre una versione lambda deriva da questo: loro immaginano una situazione in cui tu non hai nessun controllo - cioè che il tuo script sarebbe caricato su una pagina di terzi di cui nulla sai.
Mozilla non ti spiega nè punto nè poco questo assunto, nè te lo spiegano altri programmatori (anche perchè di solito nemmeno a loro è chiaro il perchè, e quindi come potrebbero dirtelo?), nè ti dice che incapsulare in questo caso significa non accorgersi delle injection: appartiene al non verbalizzato: obscurum per obscurius, il che porta ad assunzioni acritiche e alle perplessità come le tue, giustamente - perchè uno vuole capire e non codificare e basta, e i forum a queste carenze possono ovviare.
Il che serve a capire che, come ti dicevo, si incapsula quando serve e non per principio: se il tuo script è su un ambiente di cui hai controllo, incapsulare a tale scopo è come mandare i Navy Seals in montagna.
Devi prima capire se sei al mare, e poi solo se hai capito questo decidi se inviare i Seals.
Il problema peraltro è che in realtà, giunti su queste soglie del programmatore senza alcun controllo sul suo ambiente di sviluppo e, quindi, con un db potenzialmente esposto a qualsiasi XSS, può capitare di molto peggio - e innanzi a questo peggio incapsulare non ti risolve più nulla.
Incapsula per Ajax: è indispensabile. Sanitizza i dati inviati al DB. Utilizza un token in html e javascript per le tue form. Queste sono le cose che contano. Affidare la sciurezza della tua applicazione ad un incapsulamento sul lato client significa non avere sicurezza, anche perchè l'incapsulamento ti maschera proprio il tentativo di injection, e tu continui a ritenere affidabile un client che ha appena provato a farlo...
E' sulla base di questa serie di considerazioni che ti dico di non preoccuparti troppo di quel che fa Google: avrà i suoi motivi. Tu preoccupati di capire il senso delle cose (che è quello che volevi fare e a cui spero si stia dando un contributo) e poi pensa alla tua applicazione.
@Jarno
Scusa l'utente TrueLies se ti risponde in arabo. Parla a nuora perché suocera intenda, era rivolto a me. Ormai interviene nelle discussioni solo se sono intervenuto io. Figurati, è un onore per me. Ma non credo che faccia un gran servizio a questo forum.
@TrueLies
Atteggiamento da ragazzino di undici anni. Come al solito ti risponderò punto per punto.
Vedo che continui a sprecare tempo a lanciare inutili strali contro il sottoscritto. Lascia stare, è una battaglia persaOriginariamente inviato da TrueLies
A parte i copia e incolla da mozilla
Sei sicuro? Esistono tanti tipi di sviluppatori, non esistono solo i webmaster. Esiste anche chi scrive script molto complessi con centinaia di variabili ma non per utilizzarli egli stesso, ma per renderli disponibili ai webmaster (script come jquery e similia). In quel caso lo sviluppatore ha il dovere di racchiudere il proprio codice in una closure se vuole che l'utente che usufruisce del suo script possa inserire con tranquillità anche altri script nella sua pagina.si tratta di variazioni sulle cosiddette enclosures. In realtà, non hai molti motivi per utilizzare questo tipo di espressioni, o perlomeno non sono pensate per evitare l' "inquinamento" degli spazi globali (anche se puoi utilizzarle a tale scopo, ma ha poco senso: uno sviluppatore conosce il suo ambiente di produzione e sa quali variabili o strutture dati vi operano).
Che ci vuoi fare, è questione di fede.Ad una variabile puoi assegnare come valore una funzione:
var foo=function(arg){alert(arg);}
ora, chiaramente:
foo('ciao'); chiama la funzione e lancia l'alert.
La sopravvivenza del valore passato all' argomento (nel nostro caso 'ciao') tuttavia non è sempre certa.
Il fatto è che succede anche con istruzioni in campo libero dopo una qualsiasi richiesta asincrona, non c'entrano niente le funzioni, né lambda né dichiarate.Se ad esempio l'argomento di foo fosse una risposta ajax (interroghi il server con ajax, e la tua funzione rimane in ascolto della risposta del server) un sintassi del tipo
var foo=function(risposta){alert(risposta);}
non funzionerebbe: siccome il server risponde dopo un certo tempo (magari mezzo secondo, ma comunque NON subito, non istantaneamente), ma la funzione è eseguita subito, si smarrisce la possibilità di assegnare il valore che a 'risposta' darà il server: la funzione si esegue SUBITO ma il server fornirà il valore di 'risposta' PIU' TARDI.
Temo di aver capito l'utilità che tu attribuisci alle closures e, ahimé, è uno degli usi più criticati che esistano. È il tipico uso simile al seguente:Una espressione invece del tipo:
var foo=function(risposta){function(){alert(risposta)} }
che incapsula una funzione dentro una funzione, consente la sopravvivenza del namespace (ed è questo il namespace che di solito si vuole preservare - quello asincrono non quello dell' oggetto window).
Siamo nell' ambito del currying e del lambda: sono trucchetti usati o per garantire la sopravvivenza degli argomenti di una funzione in un ambiente dove tale sopravvivenza non è certa, o per passare funzioni come argomenti di altre funzioni.
Non ti preoccupare del gran mal di testa: è uno di quegli argomenti che devi sfruttare così: archivi la sua esistenza, poi quando un giorno ti troverai innanzi alla necessità in un tuo codice di fare sopravvivere un argomento di funzione o di passare una funzione come argomento ad una altra e troverai delle difficoltà, ti ricorderai di questo argomento e sarà allora, applicandolo ai tuoi codici, che lo capirai meglio.
Il nostro caro amico così intento agli obiettivi pratici immagino che non si curi del fatto che verranno create tante closures per quanti sono i link della pagina. Immagino che volutamente ignori le tante soluzioni alternative che non generano closures, come l'uso di getUserData e setUserData, degli id o dell'operatore let:codice:link n. 1 link n. 2 link n. 3 link n. 4 link n. 5 link n. 6</p> <script type="text/javascript"> function restituisciAlert (nId) { return function() { alert("hai cliccato sul link numero" + nId); return false; }; } var aLinks = document.links; for (var iLnkId = 0; iLnkId < aLinks.length; iLnkId++) { aLinks[iLnkId].onclick = restituisciAlert(iLnkId + 1); } </script>
Uso di getUserData e setUserData:
Uso degli id:codice:link n. 1 link n. 2 link n. 3 link n. 4 link n. 5 link n. 6</p> <script type="application/javascript"> function alclick () { alert("hai cliccato sul link numero" + this.getUserData("numero")); return false; } for (var iLnkId = 0, aLinks = document.links; iLnkId < aLinks.length; iLnkId++) { aLinks[iLnkId].setUserData("numero", iLnkId + 1, null); aLinks[iLnkId].onclick = alclick; } </script>
Uso dell'operatore let:codice:link n. 1 link n. 2 link n. 3 link n. 4 link n. 5 link n. 6</p> <script type="application/javascript"> function alclick () { alert("hai cliccato sul link numero" + /\d+/.exec(this.id)); return false; } for (var iLnkId = 0, aLinks = document.links; iLnkId < aLinks.length; iLnkId++) { aLinks[iLnkId].id = "mioLink" + String(iLnkId + 1); aLinks[iLnkId].onclick = alclick; } </script>
codice:link n. 1 link n. 2 link n. 3 link n. 4 link n. 5 link n. 6</p> <script type="application/javascript;version=1.7"> var aLinks = document.links; for (var iLnkId = 0; iLnkId < aLinks.length; iLnkId++) { let nThisId = iLnkId + 1; aLinks[iLnkId].onclick = function () { alert("hai cliccato sul link numero" + nThisId); return false; }; } </script>È dura non capire a fondo un linguaggio, eh?Quanto a capirlo completamente, no non accadrà: per quale motivo questo incapsulamento esita in questo tipo di comportamento infatti deriva solo dalla maniera in cui è stato progettato l'interprete javascript e non da alcuna virtù misteriosofica delle espressioni lambda che si autoimporrebbe a javascript: javascript si comporta a questo modo perchè degli essere umani lo hanno istruito a comportarsi in questo modo - è una convenzione, non una forza della natura che si rivela.
A parte il fatto che il codice che ho postato io non genera closures (sei sicuro di aver capito a fondo cos'è una closure? guarda che non basta avere una funzione per avere una closure!) e a parte gli errori di approccio al problema in questione contenuti nella tua funzione, che senso ha scrivere un oggetto con una chiave contenente una funzione che popola l'oggetto medesimo? Non era molto più sensato scrivere la funzione fuori dall'oggetto?? Mi spieghi quante closures in meno genera la tua funzione?? La funzione che avevo postato non è minimale per il semplice fatto che è in grado di interpretare numeri come numeri, booleani come booleani, etc etc. Se vuoi puoi rendere minimale anche quella:Ah scusa, per completezza di discorso e per verificare come spesso si faccia uso di enclosures senza che ve ne sia alcun motivo reale (per questo sottolineavo che la funzioni in currying o lambda ha senso usarle quando serve, e non solo perchè lo si può: è inutile sparare ai canarini con i carri armati):
se tu hai una pagina con una query, che so:
nomepagina.php?yourVar=2&pippo=ciao it's good to see you
La struttura dati minimale:
var getVars={
'foo': function(){ var s=window.location.search.substring(1).split('&'); for(var i in s){this[s[i].substring(0, s[i].indexOf('='))]=unescape( s[i].substring(s[i].indexOf('=')+1) );} return this;}
};
alert(getVars.foo().pippo);
alert(getVars.foo().yourVar);
ti esegue quanto desiderato, cioè ottenere un oggetto dove siano raccolte come proprietà gli elementi della query, in maniera semplicissima e più leggibile. (meglio ancora sarebbe non mettere il return this e invocare una volta sola foo(), in maniera da non ripopolare, e poi invocatolo una volta sai che disponi delle proprietà: semplice e diretto allo scopo, e senza inquinare alcun namespace che non sia quello già impiegato di getVars).
Interessante poi l'uso dell'operatore in con gli array… Se esegui il codice seguente con un vecchio browser ti comparirà anche la chiave length nell'alert. Non è un caso che si tratti di una scrittura sconsigliata.codice:var oGetVars = new (function(sSearchStr) { if (sSearchStr.length > 1) { for (var iCouple, iCouplId = 0, aCouples = sSearchStr.substr(1).split("&"); iCouplId < aCouples.length; iCouplId++) { this[iCouple = aCouples[iCouplId].split("="), unescape(iCouple[0])] = iCouple.length > 1 ? unescape(iCouple[1]) : ""; } } })(window.location.search);
codice:var aAnimali = ["cane", "gatto", "topo"]; var sPrint = "L'array contiene le seguenti chiavi:"; for (var sChiave in aAnimali) { sPrint += "\n" + sChiave + ": " + aAnimali[sChiave]; } alert(sPrint);Definizione di barocco a parte, potrei essere d'accordo sull'aspetto didattico di siti come il Mozilla Developer Center. Il didatta della funzione in questione però è il sottoscritto, sono stato io a postarla, in seguito a una discussione nata proprio in questo forum.Poi puoi aggiungerci qualche dettaglio ma quello che mi preme sottolineare è che il fatto che tu veda su megasiti come Google o come Mozilla delle implementazioni barocche (il loro scopo di solito è meramente didattico: non ti suggeriscono che tu debba fare così, ma solo ti segnalano una prassi possibile: sta a te capire che l'intento didattico non coincide con l'incoraggiamento ad applicare la soluzione indiscriminatamente), non deve indurti a pensare che quelle implementazioni siano necessarie: come Feyerabend disse una volta, il fatto che sotto una soluzione inutile siano collezionate delle firme scientifiche autorevoli non rende la soluzione più utile ma la rende solo "una enciclica scientifica".
@JarnoNon perdere quindi il capo su quel che fa Google (che magari avrà i suoi motivi per fare le cose, ma il loro 'backstage' non ci è giustamente noto, o magari non li avrà): archivia il fatto che il currying e le espressioni lambda sono possibili, e poi usale quando ti accorgerai che davvero possono servirti e risolverti un problema, non iniziare ad usarle solo perchè si può o perchè rende il tuo codice più "cool" a vedersi
Non perdere tempo con Google o con il Mozilla Developer Center, ascolta il buon TrueLies
Approcci meno orientati all'obiettivo pratico??? Meno male che c'è lui.Originariamente inviato da TrueLiesO, almeno, io ti suggerisco di imparare a programmare così: in maniera funzionale, e non estetica, mettendo nella tua faretra le soluzioni che oggi non ti servono per quando ti accorgerai che ti servono.
Poi, beninteso, liberissimo di seguire altri approcci meno orientati all' obbiettivo pratico. Nulla in contrario.
@Jarno
Scusaci, è che TrueLies non riesce proprio a farne a meno di mettersi in ridicolo.
Valuta da te Jarno.
Non so perchè alcuni utenti indirizzino insulti ad personam con tanto di '@'. Io non lo faccio. Nè so perchè alcuni utenti pensino che su un forum pubblico non sia legittimo prendere spunto da codici per valutarli e criticamente argomentarli e non per assumerli come come vangelo.
Io trovo i codici di mozilla assai discutibili talora (è questo il caso)- o per lo meno non li trovo istruttivi: suggeriscono delle prassi che hanno poco senso (come il premettere un prefisso che denoti il tipo di dati in un linguaggio nato come non fortemente tipizzato: un vero e proprio nonsense) e spesso propone codici senza fornire spiegazioni sulla loro applicabilità reale: cioè Mozilla non ti dice se e quando e perchè un certo codice può servire.
Comunque che sia chiaro che io sono qui per parlare di programmazione e non per parlare a questo o quello, anche se uno può pensarlo e poi da quel momento in poi è come diceva John Locke: "è convinto perchè si è convinto: non ha senso seguirlo su questa strada". Ah e però non sono nemmeno qui per sentirmi indirizzare epiteti a ripetizione.
Ho le spalle larghe e so come non rispondere a tono (come si vede. Francamente, mi scivolano proprio via), ma questa cosa comunque non va bene.
Discutere di codici senza doversi vedere rivolgere epiteti ad personam solo per via di permalosità o perchè ci si sente chiamati personalmente in causa (o non so che, nè so perchè), costituisce una aspettativa minimale nella partecipazione su forum pubblici. Grazie.
@TrueLies
Non è questione di essere permalosi. È che davvero ormai intervieni solo in maniera provocatoria nei confronti del sottoscritto. Come qui ad esempio, dove non si capisce il senso del tuo intervento. O non so se ti rendi conto di quello che hai combinato in quest'altra discussione, dove ti sei esplicitamente messo a insultarmi senza motivo, così, dal nulla, su questioni offtopic. Io mi rivolgo a te solo in risposta a tuoi interventi, non mi metto mai a criticarti su questioni offtopic e di punto in bianco. Anzi, mi sembra che quando proponi soluzioni valide in una discussione io le citi in maniera positiva. È che è proprio evidente che ti brucia per qualche strano motivo. Fattelo passare!!!!
Ho cercato comunque, pur nello stile pamphlettistico del post, di portare contributi utili a tutto forum. Siamo capaci di chiuderla qua?
Permessi di invio
