Oui oui, j'ai vu. Ça excuse pas certaines choses, comme ça par exemple:
1
2
3
4
>{}+[]// logique IMPARABLE0>[]+{}// fuck la commutativité"[object Object]"
Alors c'est joli de parler de commutativité, mais dire que si a + b != b + c alors il n'y a pas de commutativité, c'est un peu pourri comme troll. La commutativité ce serait par exemple a + b = b + a, évidemment que a + b != b + c.
>{}+[]// logique IMPARABLE0>[]+{}// fuck la commutativité"[object Object]"
Pour n'importe qui qui commence, si ce comportement est réel, il est débile. Et il devrait le rester, même pour un dev expérimenté. L'addition fonctionne naturellement que ce soit a + b ou b + a, ça devrait être pareil ici. Si ça produit une erreur dans un sens, ça doit produire la même erreur dans l'autre dans le cas présent, par simple question de logique pour moi. Surtout qu'obtenir 0 n'est absolument pas logique. Une TypeError ou InvalidOperator ou un truc du genre serait probablement mille fois plus adapté et clair que ça je pense.
On est d'accord. Même si il y a des cas de comportements pas intuitifs du genre non-associativité sur les calculs en flottants dans la norme IEEE754, on comprend pourquoi. Là je vois ça je me dis que y'a aucune raison de ne pas avoir de commutativité, et du coup Javascript j'y toucherai pas avec une perche de 10 mètres (j'aime pas le dev web de toute façon et j'aime le typage statique et fort, donc…)
L'addition fonctionne naturellement que ce soit a + b ou b + a, ça devrait être pareil ici.
Oui, mais comme je l'ai déjà dit, ici on est plus proche a + b et b + c (pour être exact, l'exemple donné est + b et b + c). Il n'y a pas de raison que + b = b + c, je me répète mais bon.
Tu parles de logique, l'article parle de commutativité, mais en quoi + [] devrait absolument être égal à [] + {} ?
Considère ce code :
1
2
3
4
{};+[];
Vraiment, je ne vois pas en quoi la commutativité ou votre logique entre en jeu ici. Ce n'est pas la même chose que :
1
[]+{};
Et il n'y a pas de raison particulièrement logique pour que ces deux snippets évaluent vers la même valeur.
Après, on est d'accord, +[] pourrait retourner d'autres choses que 0. Mais bon.
Vraiment, je ne vois pas en quoi la commutativité ou votre logique entre en jeu ici. Ce n'est pas la même chose que :
Je n'y connais pas grand chose, mais est-ce que la commutativité n'entrerait pas en jeu justement parce qu'en inversant les deux termes ce n'est pas la même chose ?
Je dis pas qu'on peut/doit pas troller JavaScript. Faites-vous plaisir. Mais s'il vous plait, trollez sur des choses qui méritent d'être trollé. Troller JavaScript en disant "oh additionner rien du tout avec un object liste ça donne pas la même chose qu'additionner un object liste avec un objet littéral, donc c'est pas commutatif", c'est pas très efficace comme troll. Tout au plus ça montre que vous connaissez pas la syntaxe de base de JavaScript.
Tenez, ouvrez la console JS de votre navigateur et faites ça :
1
2
3
vara={};varb=[];console.log(a+b===b+a);
Moi j'obtiens true. Mais c'est pas la même chose qu'un block vide plus un objet liste vide. Et un block vide plus un objet liste vide, il n'y a pas de raison que ça soit identique à un objet liste vide plus un objet littéral vide.
Excuse nous d'attendre d'un language une syntaxe logique, et des opérations habituellement communitative dans le reste de l'univers qu'elles le soient aussi en javascript.
et des opérations habituellement communitative dans le reste de l'univers qu'elles le soient aussi en javascript.
Sauf que là, ça n'a rien à voir avec une quelconque commutativité puisque les objets (au sens mathématique) additionnés ne sont pas les mêmes dans les deux cas.
Puis bon, hein, il y a des tas d'objets pour lesquels l'addition n'est pas commutative (tout ce qui est liste ordonnée au sens large, par exemple). Donc honnêtement, dire que de manière générale {} + [] et [] + {} devraient donner le même résultat parce que l'addition est commutative pour beaucoup d'objets mathématiques, c'est particulièrement fallacieux. J'aurais même plutôt tendance à m'attendre que ce ne soit pas le cas.
Pour moi tu ne montres pas ici que JS est intelligent mais que C suis la même logique étrange. Une chose fausse ne devient pas vraie quand on la compara à la même chose fausse écrite différemment.
Alors je vais pas te faire une liste des langages qui utilisent des accolades pour créer des blocks et qui ignorent les blocks vides, il y en a beaucoup trop. Je ne vais pas non plus te faire une liste des langages dans lesquels "+a == a" quand "a" est un nombre, là aussi il y en a énormément. Je ne vais pas non plus te donner l'intersection de ces deux listes pour te montrer que le comportement montré ici est extrêmement répandu. Allez, pour le fun prenons la liste des langages les plus utilisés ces temps, le célèbre TIOBE Index. Aux premières places, Java, C, C++, C#. Un peu plus bas, PHP, JavaScript. Alors, je prétends pas que ces langages sont bien foutus, de loin pas. Mais tu crois pas que s'ils sont d'accord pour autoriser le programmeur à faire des blocks et ne pas interdire les blocks vides il y a une bonne raison ?
Tu parles de chose fausse, mais qu'est-ce qui est faux ? Tu parles de logique étrange, admettons, c'est étrange pour toi, mais est-ce que tu trouverais vraiment plus logique que la spec des langages en question dise "{ … } sert à définir un block, mais un block vide est une erreur de syntaxe" ? Ou alors "la ligne sur laquelle un block se ferme ne peut contenir qu'un seul caractère : l'accolade fermante" ?
Réfléchis un peu à ces trois question, j'aimerais comprendre ce qui te semble aussi scandaleusement faux.
Personne n'a prétendu que JS était intelligent. Par contre vraiment, je l'ai déjà dit genre 3x, si tu veux continuer à troller JS c'est pas un problème, mais troll les parties de JS qui sont mal-foutues, pas les trucs tout à fait justifiables comme le comportement que je montre ici.
Bah je sais pas toi mais personnellement je préfère éviter de faire chier un loup, imagine qu'il ait la dalle, après ça on risque de devoir appeler quelqu'un avec des gants, un sac poubelle et une petite cuiller.
Connectez-vous pour pouvoir poster un message.
Connexion
Pas encore membre ?
Créez un compte en une minute pour profiter pleinement de toutes les fonctionnalités de Zeste de Savoir. Ici, tout est gratuit et sans publicité.
Créer un compte