Typoskript Unterschrift des Versprechens # Fang onrejected Handler

Ich stelle fest, die Standard-Typisierung für Promise#catch in es6-shim.d.ts definiert alsTyposkript Unterschrift des Versprechens # Fang onrejected Handler

interface Promise<T> { 
    catch(onrejected?: (reason: any) => T | PromiseLike<T>): Promise<T>; 
    catch(onrejected?: (reason: any) => void): Promise<T>; 
}

Ich frage mich, warum dies so geschrieben wird, statt als

catch(onrejected?: (reason: any) => T | PromiseLike<T> | void): Promise<T>;

Eine andere Datei es6-promise.d.ts von Nate Archibald gibt eine einzige Signatur von

catch<U>(onRejected?: (error: any) => U | Thenable<U>): Promise<U>;

bezieht sich überhaupt nicht auf <T>.

Also ist die zweite überladene Signatur in es6.shim-d-ts, die, soweit ich weiß, in einer Compile-to-ES5-Umgebung stark verwendet wird, unnötig/unerwünscht?

Quelle

2016-08-29 Anonymous

Nun, T kann void sein, was bedeutet, dass Ihr Anwendungsfall bereits unterstützt wird.

Wenn Sie T | PromiseLike<T> | void getan haben, könnte die Ausgabe eine Promise<string> sein, die mit void gelöst wurde, was ein Typfehler wäre.

Beachten Sie, dass Versprechen in diesen Definitionen nicht statisch stark typisiert werden. Die Signatur ist tatsächlich schwieriger, da reasonany eingegeben wird. Dies ist wie bei den meisten Sprachen (wie C#), bei denen keine Ausnahmen aktiviert sind, und im Gegensatz zu Java und Swift, die überprüfte Ausnahmen aufweisen (ein Teil der Signatur einer Funktion ist das, was sie werfen könnte).

Quelle

2016-08-29 11:16:12

Willst du damit sagen, dass es eigentlich 'catch (onrejected ?: (Grund: any)) => void) sein sollte: Promise '? Ich bin mir nicht sicher, woher das 'T' kommt. – Bergi

Oder wahrscheinlich sollte es wirklich eine Verbindung zwischen dem Typ des Arguments des Empfängers und dem Callback-Rückgabetyp sein, aber das könnte zu kompliziert sein. – Bergi

@Bergi T ist ein generischer Parameter des Versprechens - es kann alles sein und die Beschränkung hält es das gleiche in der Kette. Ich sage, es sollte eigentlich 'Promise ' sein, wenn wir genau sein wollen, wo S für die Ablehnung ist und 'dann' sollte dann sein :: Promise -> ((T -> Promise | S) | undefined) | E -> Versprechen | S) | undefined) -> Versprechen 'das ist immer noch nicht genau, aber mehr" sicher "- das wäre natürlich zu kompliziert für unser eigenes Wohl :) –

Typoskript Unterschrift des Versprechens # Fang onrejected Handler

Antwort

Verwandte Themen