Warum produziert der && Operator den Typen des zweiten Operanden

Question

Warum produziert der && Operator den Typen des zweiten Operanden

stimmen

24

Typoskript Spezifikation legt fest , in §4.15.6 über den &&Betreiber:

Der && Operator erlaubt die Operanden von jeder Art zu sein , und erzeugt ein Ergebnis des gleichen Typs wie der zweiten Operanden .

In Javascript, der &&kehrt Operator die ersten Operanden , wenn es falsy ist, andernfalls gibt es den zweiten Operanden ( siehe ECMA-262 §11.11 ).

Das heißt, wenn der linke Operand falsy, &&wird einen Wert zurück, der den Typ des linken Operanden übereinstimmt. Beispielsweise,

typeof ( false && {}      ) === boolean // true
typeof ( ''    && 1       ) === string  // true
typeof ( null  && hello ) === object  // true
typeof ( NaN   && true    ) === number  // true

Typoskript, nach der Regel oben zitierten, würde fälschlicherweise die Typen der obigen Ausdrücke sagen voraus zu sein Object, Number, Stringund Boolean, respectively.

Bin ich etwas fehlt? Gibt es einen guten Grund , die Art eines machen &&Ausdruck entsprechen den Typ des zweiten Operanden? Sollte nicht das Ergebnis Typen wie der Verhalten ||Operator und gibt die beste allgemeinste Art der beiden Operanden, und Anywenn es keine besten allgemeinste Art ist?

types typescript

Veröffentlicht am 02/10/2012 um 16:50
quelle vom benutzer Peter Olson

In anderen Sprachen...

1 antworten

Ryan Cavanaugh · Accepted Answer · 2012-10-02 17:55

Lange Rede kurzer Sinn, gibt es keine Lösung hier, die jeder gefällt.

Betrachten Sie dieses gemeinsame Idiom:

var customer = GetCustomer(...); // of type 'Customer'
var address = customer && customer.address;
if(address) {
    printAddressLabel(address); // Signature: (Address) => void
} else {
    // Couldn't find the customer or the customer has no address on file
}

Es wäre ziemlich lahm aufgeben und entscheiden, dass ‚Adresse‘ ist ‚any‘, weil es keine beste allgemeinste Art zwischen dem Kunden und Adresse.

In der Mehrzahl der Fälle , in denen der Operator && verwendet wird , entweder die Typen bereits übereinstimmen oder && wird in einem Wert-koaleszierenden Weise wie oben verwendet. In jedem Fall die Art des rechten Operanden der Rückkehr gibt dem Benutzer die erwarteten Typ.

Während die Typsicherheit technisch an diesem Punkt nach unten bricht, tut es nicht so in einer Weise, die zu einem Fehler führen wahrscheinlich ist. Entweder Sie gehen zu dem resultierenden Wert für Truthiness Test (in diesem Fall die Art mehr oder weniger irrelevant ist), oder Sie gehen zu den vermutlichen rechten Operanden für einige Operation verwenden (das obige Beispiel beide tun).

Wenn wir an den Beispielen sehen Sie die linke Operand aufgelistet und so tun , als indeterminately truthy oder falsy und dann versuchen , gesund , Code zu schreiben , die auf dem Rückgabewert arbeiten würde, wird es viel klarer - es gibt einfach nicht viel können Sie tun mit ‚false && {} jede Argument Position oder Truthiness Test‘ , die nicht bereits in einem gehen".

Nachtrag

Da einige Leute nicht durch die oben überzeugt waren, hier ist eine andere Erklärung.

Lassen Sie uns einen Moment lang so tun , dass das Typoskript Typ - System drei neue Typen hinzugefügt: Truthy<T>, Falsy<T>, und Maybe<T>, was möglich truthy / falsy Werte des Typs T. Die Regeln für diese Typen sind wie folgt:

Truthy<T> verhält sich genau wie T
Sie können keinen Zugriff auf alle Eigenschaften von Falsy<T>
Ein Ausdruck der Art Maybe<T>, bei der als Bedingung in einem verwendeten ifBlock, wird ein Truthy<T>in dem Körper desselben ifBlöcke und einem Falsy<T>in dem elseBlock

Dies würde Sie Dinge tun, wie folgt:

function fn(x: Maybe<Customer>) {
   if(x) {
      console.log(x.address); // OK
   } else {
      console.log(x.phone); // Error: x is definitely falsy
   }
   console.log(x.name); // Warning: x might be falsy!
}

Ziemlich gut so weit. Jetzt können wir herausfinden, was die Art Regeln sind für den Operator &&.

Truthy<T> && x sollte ein Fehler sein - wenn die linke Seite zu sein truthy bekannt ist, sollten Sie gerade geschrieben haben x
Falsy<T> && xein Fehler sein sollte - wenn die linke Seite falsy zu bekannt ist, xist nicht erreichbar Code
Maybe<T> && x sollte produzieren ... was?

Wir wissen , das Ergebnis Maybe<T> && xentweder ein falsy Wert vom Typ sein T, oder x. Es kann nicht produzieren Truthy<T>(es sei denn , T== die Art der xdiese gesamte in diesem Fall Diskussion ist strittig). Lassen Sie sich diese neue Art nennen Falsy<T> XOR Maybe.

Was sollten die Regeln Falsy<T> XOR Maybesein?

Natürlich können Sie nicht Eigenschaften verwenden Tauf sie. Wenn der Wert des Typs ist T, dann ist es falsy, und nicht sicher für den Einsatz.
Sie sollten es als ein der Lage sein , zu verwenden Maybe, da Falsy<T>und Falsyhaben die gleichen Verhaltensweisen
Sie sollten Eigenschaften zu benutzen , nicht in der Lage U, weil der Wert noch falsy sein könnte.
Wenn Sie es in einem verwenden ifTest, dann sollte es ein sich Truthyin dem Block von dieser ifAussage

Mit anderen Worten Falsy<T> XOR Maybe ist Maybe . Es folgt den gleichen Regeln. Sie müssen nicht durch das Hinzufügen dieser seltsame den Typen System überhaupt hier erschweren XORArt, weil ein Typ, der die Spezifikationen alles , was Sie bereits vorhanden benötigen paßt.

Das ist ein bisschen wie jemand eine Box geben und sagen: „Das ist entweder ein leeres Feld von Müll, oder eine volle Schachtel recyclables“. Sie können sicher den Inhalt der Box in den Papierkorb leeren.