Newsgroup: it.comp.lang.javascript
Titolo: warning validatore

Ho uno script con questo codice:
for(j=a.length;j--;)
	a[j].currentStyle.k && c.push(a[j]);
 
il validatore mi avvisa:
Expected an assignment or function call and instead saw an expression.
 
Come la devo variare per evitare il warning?
 


a[j].currentStyle.k
forse intendevi
 
a[j].currentStyle = k ?
-- 
I fatti mi cosano

 ha scritto:

qui è letterale:
http://www.codecouch.com/2012/05/adding-document-queryselectorall-support-to-ie-7/
 
 


Eh, chiedi a loro allora
Dal basso della mia ignoranza quel codice non fa nulla: non assegna 
nulla a k e non richiama k come funzione, viene solo valutato come 
espressione il che peraltro è quello di cui si lamenta il "validatore" pare
Un approccio folle nella sua temerarietà potrebbe essere di provare ad 
assegnar un qualcosa a k tipo 'a' giusto per vedere se il warning se ne 
va, ma non è più tempo di temerari
M


 Come la devo variare per evitare il warning?
 
Ammesso che tutte le variabili siano dichiarate altrove:
 
    for (j=a.length;j--;)
        if (a[j].currentStyle.k)
            c.push(a[j]);
 
Guarda se cosí al validatore piace.
 
In ogni caso non c'è niente di sbagliato nella riga incriminata; è una
questione di stile. Se ho ben capito il codice è fatto per usare meno
byte possibili – per questo non ci sono spazi nel `for`, ad esempio – e
in tal ottica la scelta di usare l'operatore logico and aveva senso.


Premetto che non amo propriamente quel tipo di scrittura, né quella che 
sto per proporti.
 
Potresti provare con:
 
for (j = a.length; j--; a[j].currentStyle.k && c.push(a[j])) ;
 
Oppure riscriverla in modo più leggibile / comprensibile e vedrai che il 
tuo validatore non opporrà resistenza.
 
Per rispondere anche a Marco: il parser in un'espressione booleana si 
ferma se la condizione è soddisfatta valutando il primo operando.
 
Quindi se "a[j].currentStyle.k" viene valutato come "false" non viene 
eseguito il push, altrimenti sì.
 
Praticamente si sono risparmiati di scrivere un "if".
 

 espressione il che peraltro è quello di cui si lamenta il "validatore" pare
 
Quel codice in pratica esegue `c.push(a[j])` solo se
`a[j].currentStyle.k` ha un valore considerato "truthy", e restituisce
il risultato di `c.push(a[j])` se eseguito, e `false` altrimenti – in
quanto l'espressione è falsa, dato che uno degli operatori non è "vero".
 
Nota che, per la stessa logica, se `c.push(a[j])` restituisse un valore
"falsy", l'espressione sarebbe ugualmente falsa. In questo caso è
indifferente perché non c'è niente che collezioni tale valore. In ogni
caso difficilmente `c.push` restituirà un valore "falsy", in quanto
restituisce la nuova lunghezza dell'array (quindi il valore è sempre
maggiore di 0).
 


Ah, ok
Ma è un comportamento idiosincratico di JS?
Dichiaro la mia ignoranza
Io ho di mio un approccio molto più "discorsivo" nella scrittura del 
codice quindi quel tipo di costrutti proprio non lo uso  e di 
conseguenza non lo conosco
Adesso che sto leggendo "Clean Code" poi ...


 quanto l'espressione è falsa, dato che uno degli operatori non è "vero".
 
Scusa, qui ho fatto un po' di confusione: l'espressione restituisce
anche il valore "falsy"; ovviamente viene comunque trattato come `false`
– appunto perché il valore è considerato una "falsità". Per intenderci:
 
    console.log(true && 0 && 1);
 
restituirà `0`.
 

 Adesso che sto leggendo "Clean Code" poi ...
 
In generale, è sempre meglio scrivere codice pulito: è piú leggibile,
soprattutto si sviluppa in team e/o Open Source. Ci sono sempre i vari
compilatori, che possono ottimizzare, minimizzare, e ridurre il codice a
posteriori.
 
Questo ovviamente, a meno che non si cerchi qualche ottimizzazione
specifica, oppure voler scrivere a mano codice in pochissimi byte
(vedasi il sito 
140byt.es
, per esempio).
 


Sono sempre più convinto che JS sia uno dei linguaggi più complessi mai 
inventati da mente umana ....
 
Grazie per la spiegazione
M


 Grazie per la spiegazione
 
Ci mancherebbe, il NG è qui apposta.

 inventati da mente umana ....
 
beh, questa cosa di valutare la "verità" di cose non booleane viene 
praticamente dritta-dritta dal c :)
 
(anche se li la logica è più semplice: 0 e NULL sono falsi, qualunque altra 
cosa è vera)
 
La cosa che mi dispiace di javascript è che avrei preferito che i container 
vuoti ( [], e anche {} se vogliamo considerarlo un container ) fossero 
considerati "falsi", ma tant'è, alla fine uno ci s'abitua...
 
-- 
ZeD
 

 considerati "falsi", ma tant'è, alla fine uno ci s'abitua...
 
Direi che questo è, appunto, un discorso d'abitudine: chi proviene da
Python, ed è abituato a tale linguaggio, può trovare strano che
JavaScript consideri "array vuoti" un valore "vero": ma per chi proviene
da linguaggi tipo C, passando per JavaScript, per poi approdare a
Python, trova strano che un "oggetto", come un array, sia considerato un
valore "falso".
 
Per quanto mi riguarda, trovo normale che gli oggetti siano considerati
"veri" – siano essi array vuoti o meno –; ciò che trovo un pelo strano –
e non solo io – è che `typeof null` dia come risultato `object`, e sia
considerato però un valore "falso": non dovrebbe restituire `object`, in
tal caso.
Ma questo è un altro discorso, e c'è un lungo dibattito in merito, e
pare che, forse, in ES6 le cose saranno diverse – almeno per ciò che
concerne lo strict mode – ma, come sempre, chi vivrà vedrà. :)

 Oppure Vigil: 
https://github.com/munificent/vigil
 
 
LOL!!!
-- 
"Un pasto senza vino e' come un giorno senza sole"
Anthelme Brillat Savarin