Miért && operátor előállítani a típus a második operandus

Question

Miért && operátor előállítani a típus a második operandus

szavazat

24

A gépelt leírás államok §4.15.6 a &&szolgáltató:

Az && operátor lehetővé teszi az operandusok, hogy bármilyen típusú és gyárt eredményeként ugyanolyan típusú, mint a második operandus .

A JavaScript az &&üzemeltető visszatér az első operandus ha falsy, különben nem adja vissza a második operandus ( lásd ECMA-262 §11.11 ).

Ez azt jelenti, hogy ha a bal oldali operandusa falsy, &&vissza fog térni az értéket, amely megfelel annak a bal operandus. Például,

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

Géppel, a szabály alapján a fent idézett volna helytelenül megjósolni, hogy milyen típusú a fenti kifejezések lenni Object, Number, Stringés Boolean, ill.

Lemaradtam valamiről? Van egy jó ok arra, hogy milyen típusú a &&kifejezést típusának megfelelően a második operandus? Amennyiben nem az eredmény típusát úgy viselkednek, mint a ||szolgáltató, és visszatér a legjobb gyakori típusa a két operandus, és Anyha nincs a legjobb közös típus?

types typescript

A kérdést 02/10/2012 16:50
a forrás felhasználó Peter Olson

Más nyelveken...

1 válasz

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

Hosszú történet rövid, nincs megoldás, hogy itt tetszik mindenkinek.

Tekintsük ezt a közös idióma:

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
}

Ez lenne elég béna, hogy feladja, és úgy dönt, hogy a „cím” a „minden”, mert nincs a legjobb gyakori típusa az Ügyfél és a cím.

A legtöbb esetben, ha az && operátor használata esetén akár a típus már egyezik, vagy && használják egy értéket coalescing módon, mint a fenti. Mindkét esetben visszatérő típus a jobb oldali operandus ad a felhasználónak a várt típusú.

Míg a típusú biztonsági technikailag összeomlanak ezen a ponton, hogy nem csinál olyan módon, hogy ez valószínűleg egy hiba. Vagy fogsz tesztelni a kapott érték truthiness (ebben az esetben a típus több vagy kevesebb nem számít), vagy fogsz használni a feltételezett jobb oldali operandus valamilyen műveletet (a fenti példában csinál mindkettő).

Ha megnézzük a példát Ön által felsorolt és úgy tesznek, mintha a bal oldali operandusa indeterminately truthy vagy falsy majd próbálja írni épelméjű kódot, ami működik a visszatérési érték, ez lesz sokkal pontosabban - ott csak nem sok mindent lehet csinálni a „hamis && {}”, hogy még nem megy be egy»minden«argumentum pozíció vagy truthiness teszt.

Függelék

Mivel néhány ember nem győzte meg a fenti, itt egy másik magyarázat.

Tegyük egy pillanatra, hogy a géppel típusú rendszer három új típusok: Truthy<T>, Falsy<T>és Maybe<T>, ami a lehető truthy / falsy típusú értékek T. A szabályok az ilyen típusú a következők:

Truthy<T> pontosan úgy viselkedik, mint a T
Nem lehet hozzáférni tulajdonságai Falsy<T>
Egy expressziós típusú Maybe<T>, ha használják, mint az az állapot, egy ifblokkban, válik Truthy<T>a szervezetben ugyanezen ifblokk és egy Falsy<T>a elseblokk

Ez engedi meg a dolgokat, mint ez:

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!
}

Elég jó eddig. Most már tudjuk kitalálni, milyen típusú szabályok vannak az && operátor.

Truthy<T> && x legyen hiba - ha a bal oldali tudvalevően truthy, akkor éppen megírt x
Falsy<T> && xlegyen hiba - ha a bal oldali tudvalevően falsy, xelérhetetlen kód
Maybe<T> && x kell készítenie ... mi?

Tudjuk, hogy az eredmény Maybe<T> && xlesz vagy egy falsy típusú érték T, vagy x. Ez nem tud előállítani Truthy<T>(hacsak T== típusát x, amely esetben ezt az egész vitát vitás). Nevezzük ezt az új típusú Falsy<T> XOR Maybe.

Mit kell a szabályokat Falsy<T> XOR Maybelenni?

Nyilvánvaló, hogy nem tudja használni tulajdonságait Trajta. Ha az érték típusú T, ez falsy, és nem biztonságos használatra.
Meg kell tudni használni, mint egy Maybe, mivel Falsy<T>és Falsyvan egyforma viselkedés
Nem kell tudni használni tulajdonságait U, mert az érték még mindig lehet falsy.
Ha ez egy ifteszt, akkor kell, hogy legyen Truthya blokk, hogy a ifnyilatkozat

Más szóval, Falsy<T> XOR Maybe az Maybe . Ebből következik, mind ugyanazokat a szabályokat. Nem kell, hogy bonyolítja a típusú rendszer minden ide hozzáadásával ez a furcsa XORtípusú, mert olyan típus, amely illeszkedik az összes specifikációt, amire szükség van már létezik.

Ez egy kicsit olyan, mint valaki ad egy dobozt, és azt mondja: „Ez vagy egy üres doboz szemetet, vagy egy teljes doboz újrahasznosítható”. Nyugodtan üres a doboz tartalmát az újrahasznosítás bin.