Pourquoi n'y a-t-il pas d'opérateurs d'affectation composés pour les opérateurs logiques (tels que ||, && etc)?

Selon ECMA-262, une partie 11.13, suivant la liste exhaustive des opérateurs d'affectation composés: *= /= %= += -= <<= >>= >>>= &= ^= |=.

Selon la partie 11.11, var c = a || bmettra de la avaleur dans csi ToBoolean(a)est vrai et mettra de la bvaleur dans csinon. En tant que tel, le OU logique est souvent utilisé comme opérateur de fusion, par exemple

function (options) {
    options = options || {};
}

Assez souvent, soudent est utilisé pour spécifier la valeur par défaut pour la variable, comme cela a été indiqué ci - dessus: a = a || b.

Il semble que l' opérateur d'affectation composé ||=serait vraiment utile, ce qui permet d'écrire le code ci - dessus de façon plus courte et plus propre: a ||= b. Cependant, il n'est pas là (bien que *=, +=et d'autres opérateurs d'affectation composés le soient).

La question est, pourquoi?

javascript language-design history

— penartur
source

Je suis incroyablement perplexe que l'opérateur% = existe même. Qui a décidé que c'était nécessaire? Certains de ces opérateurs semblent être de mauvaises décisions de conception de langage.

— Jonathan Rich

@JonathanRich: pourquoi ne pas avoir% =? Si vous prévoyez d'avoir l'un de ces opérateurs d'affectation, tôt ou tard, certains développeurs (comme penartur) se demanderont pourquoi les opérateurs sont "plus égaux" que les autres.

— kevin cline

@JonathanRich Crypto utilise de manière significative le module. Furthemore, il y a un orthogonalité désiré avec le reste de l'arithmétique aux opérateurs d'affectation arithmétique (si l' on attend +=, *=, -=, /=, pourquoi pas le %=travail?).

@JonathanRich: L'opérateur est utile lorsque vous avez quelque chose de circulaire et que vous voulez le normaliser, par exemple angle %= 360ou vertexIndex %= numberOfVertices(pour la liste des sommets d'un polygone fermé).

— Sebastian Negraszus

Notez qu'en 2007 (quelqu'un qui prétend l'être), Brendan Eich a déclaré ||=et &&=viendrait bientôt: "Vous serez peut-être heureux d'apprendre que pour JS2 / ES4, || = et && = sont également ajoutés. || = est le plus utile des deux, mais il n'y a aucune raison de laisser la forme affectation-op de && out. " .

— Phrogz

Réponses:

Une raison possible est que les opérateurs logiques &&et ||ont un comportement « court-circuit ». L'opérande de droite de &&et ||n'est évalué que si cela est nécessaire. C'est peut-être pour cette raison que les concepteurs de langage ont décidé que le sens d'une expression comme a ||= f()n'était pas évident, et que de tels opérateurs étaient donc mieux laissés de côté.

— Kevin Cline
source

Oui. Par exemple, beaucoup de gens croient que cela a ||= bdevrait être interprété comme a = a || b, mais en fait cela peut l'être a || a = b(comme dans Ruby ). Ils peuvent être différents si le setter a un effet secondaire. Le choix de l'un peut être mauvais pour les utilisateurs de l'autre camp. Personnellement, j'aime la a || a = bmanière (la manière Ruby), mais je ne sais pas si tout le monde est satisfait de cela.

— Franklin Yu

La réponse générale à toutes les questions sur «pourquoi cette fonction de langue n'a pas été implémentée» est que l'équipe qui a conçu la langue a décidé que l'avantage ne l'emportait pas sur le coût.

Le coût peut prendre plusieurs formes. Il faut du temps et des efforts pour mettre en œuvre une fonctionnalité de langue, mais il y a aussi le coût intrinsèque de la complexité: la fonctionnalité rend-elle la langue plus complexe ou ambiguë, hors de proportion avec son avantage potentiel?

L' ||=opérateur hypothétique fait quelque chose de fondamentalement différent des autres opérateurs d'affectation composés. Alors que les autres opérateurs sont de nature purement mathématique, celui-ci est différent: il substitue une valeur à une autre (dans le contexte que vous avez décrit).

Compte tenu de cette ambiguïté (l'opérateur remplit deux fonctions différentes, selon le contexte), il n'est pas difficile de voir pourquoi il n'a pas été inclus dans le langage. Bien que vous déclariez que changer

function (options) {
    options = options || {};
}

function (options) {
    options ||= {};
}

effectuer une coalescence nulle est une caractéristique précieuse, l'avantage est beaucoup moins clair pour moi. Si une substitution de valeur doit se produire, il semble logique (et plus clair) d'avoir les deux valeurs sur le côté droit du signe égal, pour fournir une indication visuelle qu'une telle substitution peut se produire.

C # a pris un chemin différent et utilise un opérateur spécifique pour la coalescence nulle.

— Robert Harvey
source

Lors de la lecture du code, le premier exemple se lit plus naturellement - "options est égal à options ou rien" - par rapport au second - "options ou est égal à rien". Je pense que c'est juste une autre raison pour ne pas inclure l'opérateur "ou égal"

— Andy Hunt

Excellente ouverture à votre réponse. Et je pense que le début de votre réponse appartient au wiki pour la balise.

@AndyBursh La même logique pourrait être appliquée à n'importe quel opérateur d'affectation composé. «X est égal à X fois 2» se lit plus naturellement que «X fois est égal à 2».

— penartur

Notez que pour taper, foo = foo || barvous devez taper foodeux fois. Ceci est à la fois lourd et susceptible de refactoriser les fautes de frappe.

— Phrogz

Je pense que vous comprenez mal le sens de «mathématique», vous avez peut-être entendu parler de l'algèbre booléenne. Je suis d'accord que la contrainte d'un non-booléen afin de l'utiliser ||=comme un opérateur de coalescence nul n'est pas intuitive et semble en fait obtuse sous forme de code. Lorsque cela devient utile, c'est lorsque vous essayez de faire des mathématiques booléennes.

function fulfill(inValue) { if(resolved || rejected) return false; /* Do stuff here */ return true; } resolved ||= fulfill(value)

— joshperry

Vous avez raison, c'est ||=une construction utile. Il existe en Perl.

En fait, Perl met tout cela à disposition:

**=    +=    *=    &=    <<=    &&=   -=    /=    
|=     >>=   ||=   .=    %=     ^=    //=   x=

Certains d'entre eux sont excellents ( .=ajoute quelque chose à la fin d'une chaîne), d'autres moins ( &&=??? Je suppose que la variable serait réglée sur le côté droit si elle et la variable sont vraies. Mais pourquoi voudriez-vous jamais faire cela ?)

Ce qui est inclus dans une langue est vraiment une caractéristique de sa philosophie de conception.

stackoverflow.com/questions/12589467/… pour ce que &&=signifie / fait.

— Mat