Newsgroup: it.comp.lang.javascript
Titolo: Uguaglianze non proprio uguali?

Una curiosità nata da un comportamento visto in Closure Compiler: se ho 
una condizione espressa così:
 
if(a == 5)
 
il compilatore la gira immancabilmente in
 
if(5==a)
 
Se la condizione ha già la costante per prima resta così com'è, quindi 
non sembra essere un side effect del compilatore (tipo che scambia 
sempre tra di loro i membri) ma una cosa voluta. Più in generale mi 
sembra che l'ordine di precedenza che applica sia costanti - variabili - 
espressioni, quindi nel confrontare 
p.es
. il risultato di una funzione 
con una variabile quest'ultima passa davanti.
 
C'è una qualche ragione (di efficienza o che altro) per fare così? Mi 
verrebbe da pensare che la proprietà riflessiva di un'uguaglianza sia 
valida anche quando viene eseguita oltre che per il risultato in sé... o 
in realtà non è così?
 
-- 
r--r--r--

 if(5==a)
 
E` un consiglio che danno in molti quando usi linguaggi dinamici come JS 
e PHP.
 
Deriva dal fatto che ci sono tre operatori con l'=:
 
= assegna un valore
== confronta due valori con cast
=== confronta l'identità assoluta di due valori (stesso valore, stesso 
tipo)
 
Quando usi == avviene una conversione implicita di tipo. Mettendo la 
costante prima della variabile "forzi" la conversione al tipo della 
costante, ed eviti alcuni errori nascosti (dalla conversione implicita).
 
Io consiglio sempre (a meno che non lo si faccia apposta) di usare === 
invece di ==.
 
Bye.

 costante, ed eviti alcuni errori nascosti (dalla conversione implicita).
 
Ah! Molto interessante, non ci avevo proprio pensato! Quindi in 
effetti... sì! X == Y non è (necessariamente) equivalente a Y == X!
 
L'uso sistematico di === non mi entra in testa: programmo poco in JS e 
quando mi capita approfitto di WebStorm che integra JSHint e JSLint che 
segnalano una sfilza di violazioni di best practice che spesso possono 
essere rimediate a colpi di click, quindi lo script lo butto giù in 
schifezza-mode e poi (quando mi ricordo) lo aggiusto... :-)
 
Grazie!
 
 
 

 
 
Precisazione: linguaggi dinamici con tipizzazione debole.
http://en.wikipedia.org/wiki/Strong_typing
 
 
 
Ciao  Manlio
 
 

 costante
 
Non sono sicuro di cosa tu intenda. In JavaScript (come da specifiche
ECMAScript) la conversione implicita durante l'eguaglianza non dipende
dall'ordine degli operandi. Avere:
 
    5 == "5"
 
O:
 
    "5" == 5
 
è indifferente. Stesso dicasi se gli operandi sono in variabili. In
entrambi i casi, JS converte l'operando che è stringa in numero, e
applica l'operatore di eguaglianza.
 
Magari in certe implementazioni può essere utile avere il valore literal
come primo operatore per una questione di lieve ottimizzazione, ma per
decidere quale strategia di conversione applicare i tipi di entrambi gli
operandi devono essere recuperati in ogni caso.
 
L'unica linea guida effettiva che io ricordi, che antepone i literal
alle variabili durante il comparison, è che in JS questo statement è
legale e risulta sempre vero:
 
    if (a = 5)
 
Mentre questo:
 
    if (5 = a)
 
Rilancia un'eccezione. Quindi c'è chi suggerisce l'uso di questa
notazione per evitare errori di assegnazione involontari durante la
stesura del codice.
 
Comunque se si prende la buona abitudine di usare lo strict equal,
difficilmente si può rischiare una cosa del genere.
 
Come te, anche io suggerisco sempre l'uso dello strict equal a meno di
rare eccezioni (e.s. undefined e null in certi casi), dato che non solo
è meno error prone, ma è anche più performante nella maggior parte dei casi.

 schifezza-mode e poi (quando mi ricordo) lo aggiusto... :-)
 
Ahah, capito. :)