Pour le fun !

**Willpower** · 22/10/2011, 04h13

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
if( "0" == !"0"){
	// eh oui, c'est pourtant vrai^^
}

désolé, il 4h du mat et je m'ennuyais.

EDIT: Après relecture je trouve mes explications peu claires donc en gros à gauche nous avons un string que nous comparons à droite à un booléen puisque le ! inverse notre valeur au format booléen. Donc notre membre de droite vaut "false" puisque le string était true (non vide). Enfin notre égalité tente donc de comparer un string ( "0" ) à un booléen ( false ) le plus court chemin (casting de type ) entre les deux est l'entier. Car pour convertir notre string ( bon la machine ne réfléchit pas exactement comme ça, mais pas loin non plus ) il suffit d'enlever les apostrophes au membre de gauche pour obtenir l'entier ( 0 ) quant au membre de droite il peut également être directement traduit en entier car les valeurs booléennes true et false valent en réalité respectivement 1 et 0. Maintenant que nos valeurs sont de même type, elle peuvent être comparées, et aussi surprenant que cela puisse paraître, 0 est bien égal à 0.^^

nb: j'ai eu tellement de problème avec ces maudits "0" que je voulais le mettre sous une jolie forme ^^

pour infos :
Boolean('0'); // TRUE (car string2bool => ('0'.length) > 0)
Boolean(!'0'); // FALSE (car !(string2bool) )
Boolean('0'==false); // TRUE (car (string2int('0')==bool2int(false)==0) est vrai)
Boolean(!'0'==false); // TRUE (car !(string2bool)==false )

je vous laisse devenir cinglés !

edit: j'espère que TOUS ceux qui liront ça, utiliseront dorénavant TOUJOURS les opérateurs "===" et "!==".

edit2: et un exemple concret bien chiant :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
var value = "0";
if(value == 0)
  VRAI;
if(!value)
  FAUX;

**MrPringle** · 22/10/2011, 07h55

Merci de partager tes lubies nocturnes.

En effet, ce genre de comportement étonnant pousse vraiment à utiliser "===" et "!==", d'autant plus que c'est le genre de bug bien chiant à pister ensuite.

**Auteur** · 22/10/2011, 14h21

Pour simple commentaire je citerai ta signature

pourquoi faire simple quand on peut faire compliqué ?

**RomainVALERI** · 26/06/2012, 16h45

...les joies du cast implicite en JS ^^'

**SpaceFrog** · 26/06/2012, 16h48

avec deux lettres inversées

**Watilin** · 26/06/2012, 17h06

Envoyé par Willpower

edit: j'espère que TOUS ceux qui liront ça, utiliseront dorénavant TOUJOURS les opérateurs "===" et "!==".

Excellent exemple !

Par contre je ne crois pas qu'il y ait conversion en Number à aucun moment. Nous avons une comparaison entre une chaîne et un booléen, et l'interpréteur n'est pas censé savoir que la chaîne représente un nombre... Je pense que la chaîne est directement castée en booléen.

**RomainVALERI** · 26/06/2012, 17h07

Envoyé par SpaceFrog

avec deux lettres inversées

Allez je me lance...

Le cast a foiré ?

**SpaceFrog** · 26/06/2012, 17h11

**Willpower** · 26/06/2012, 19h08

Envoyé par Watilin

Excellent exemple !

Par contre je ne crois pas qu'il y ait conversion en Number à aucun moment. Nous avons une comparaison entre une chaîne et un booléen, et l'interpréteur n'est pas censé savoir que la chaîne représente un nombre... Je pense que la chaîne est directement castée en booléen.

Je n'en suis pas certain, mais je pense bien que la comparaison se fait sur des entier, car sinon :

Boolean("0") valant "VRAI"
on en revient à VRAI==!(VRAI) => FAUX

Or si on passe par des Number :

Number("0") => 0
Number(!(VRAI)) => 0
0==0 => VRAI

En résumé ça donne ça :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

alert(Number('0')==Number(Boolean('0')));

**Watilin** · 26/06/2012, 19h50

Mais pourquoi caster un booléen en nombre ? Je ne comprends pas.
Je pense que le seul moyen de nous départager, ce serait d'aller voir dans les codes sources des différents navigateurs ^^

**Willpower** · 26/06/2012, 20h20

Envoyé par Watilin

Mais pourquoi caster un booléen en nombre ? Je ne comprends pas.
Je pense que le seul moyen de nous départager, ce serait d'aller voir dans les codes sources des différents navigateurs ^^

Je ne sais pas mais la comparaison n'est pas booléenne en tout cas car :

Boolean('0') != false
true != false

Elle n'est pas de type string non plus car :

'0' != String(false)
'0' != 'false'

Tandis que

Number('0') == Number(false)
0 == 0

je pense que les navigateurs ont des règles de casting probablement communes à tous les navigateurs, mais si qqn à un article là dessus, il est le bienvenu.

edit: réponse ici : http://bclary.com/2004/11/07/#a-11.9.3
(ligne 18)

sinon article intéressant en bonus ici : http://bonsaiden.github.com/JavaScri...#types.casting

**Watilin** · 27/06/2012, 02h47

Si c’est l’ECMA qui le dit, alors je m’incline

Ça me paraissait juste plus simple de tout passer en booléen, étant donné que ça prend moins de place. Le type Number occupe quand même 8 octets !

Sinon intéressante lecture en effet. J’ai toujours eu tendance à éviter les constructeurs d’objets natifs (new Array(), new String(), etc.) parce que je trouve ça moche, mais maintenant j’ai une bonne raison de le faire

**Willpower** · 27/06/2012, 03h11

Envoyé par Watilin

Si c’est l’ECMA qui le dit, alors je m’incline

Ça me paraissait juste plus simple de tout passer en booléen, étant donné que ça prend moins de place. Le type Number occupe quand même 8 octets !

Sinon intéressante lecture en effet. J’ai toujours eu tendance à éviter les constructeurs d’objets natifs (new Array(), new String(), etc.) parce que je trouve ça moche, mais maintenant j’ai une bonne raison de le faire

Attention l'array(comme l'objectObject : constructeur par défaut) étant TOUJOURS un object, le new n'a aucun effet sur la valeur de retour du constructeur(un object), par contre les string et les numbers étant des primitives, faire un "new string()", revient à créer un "object" contenant le string(primitif), ça ne sert pas à grand chose car le seul avantage est d'ajouter des méthodes sur l'objet, or la valeur de l'objet étant une primitive, elle ne peut être affectée, tu ne peux pas la modifier autrement dis, la modification d'une primitive crée en quelques sortes une autre primitive.

Pour t'en convaincre :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
a = b = new String("lol");
a+="lol";
alert( a); // "lollol" : typeof = string (nouvelle primitive)
alert( b); // "lol" : typeof = object

Disons, que la seule utilité est éventuellement pour des constantes (number ou string) avec des méthodes "getter" (un stack ou un fixed ..)

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
pi = new Number(3.14159);
pi.val = function(){
	return this.toFixed(2);
};
alert( pi.val());
alert( pi);

**Willpower** · 27/06/2012, 04h13

Conclusion:

"0" == !("0")
"0" == !(Boolean("0"))
"0" == !(true)
"0" == false
=> on commence la comparaison grâce au tableau : http://bclary.com/2004/11/07/#a-11.9.3
"0"(x) == false(y)
step: 1,14,15,16,17,18,19
"0" == Number(false)
"0" == 0
"0"(x) == 0(y)
step: 1,14,15,16,17
Number("0") == 0
0 == 0
0(x) == 0(y)
step: 1,2,3,4,5,6,7
return true

bref, il ne s’ennuie pas le navigateur pour une simple comparaison ^^