Eine Zusage stellt einen Wert dar, der in Zukunft verfügbar sein könnte (oder auch nicht).
Was ich suche, ist ein Datentyp, der einen verfügbaren Wert darstellt, der in Zukunft möglicherweise nicht mehr verfügbar ist (möglicherweise aufgrund eines Fehlers):
%Vor%Wurde ein solches Konzept (oder ähnliches) bereits erforscht? Gibt es existierende Semantiken oder gebräuchliche Idiome?
Beispielsweise könnte es eine offene Datenbankverbindung darstellen, die geschlossen wird. Mein besonderer Anwendungsfall wäre die Darstellung von "veränderbaren", dh variablen Mengen in FRP als ein Strom solcher "Ending-Werte" - wenn ein Ereignis auftritt, wird der Wert zum Satz hinzugefügt und wenn der Wert "endet "Es ist entfernt.
Ich hatte das Gefühl, dass dies als Signal<Option<value>> oder {data = value, ended = Promise<null>} dargestellt wird. Der erste Fall beinhaltet nicht die Garantie, dass der Wert sich letztendlich auf Nothing und der zweite auf data bezieht. Feld nach dem Ende noch zugänglich.
Im Beispiel der DB-Verbindung haben Sie konzeptionell eine Folge von DB-Verbindungen, jedes Mal, wenn Sie auf den Wert zugreifen, den Sie (möglicherweise asynchron) aus der Sequenz (einer Verbindung) erhalten. Die Ausbeute kann asynchron sein, und der Wert selbst kann auch asynchron sein. Die Sequenz könnte enden (sie wird nie wieder verfügbar gemacht) oder sie könnte immer das Ergebnis liefern - sie könnte ausstehen und niemals wieder eine Verbindung herstellen.
Es ist erwähnenswert, dass ein asynchroner Generator eine große Obermenge des Typs ist, nach dem Sie suchen - er ist viel expressiver und ist nicht direkt umgekehrt.
Sie können ein Versprechen auf verschiedene Arten umkehren.
Ein Versprechen ist eine singular zeitliche Getter . Das ist das Folgende:
Zitieren Kris 'Arbeit über die Zeitlichkeit von Versprechen :
Ein Beobachter kann abonnieren, um schließlich den Wert eines Versprechens zu sehen. Sie können dies tun, bevor oder nachdem das Versprechen einen Wert hat. Eine beliebige Anzahl von Beobachtern kann mehrere Male abonnieren und jeder einzelne Beobachter kann das gleiche Versprechen mehrere Male abonnieren .... Versprechen sind broadcast . Das Gesetz, dass kein Verbraucher in einen anderen Verbraucher eingreifen kann, macht es unmöglich, dass laufende Arbeiten abgebrochen werden. Ein Versprechen stellt ein Ergebnis dar, nicht die Arbeit, die zu diesem Ergebnis führt.
Das Gegenteil einer Verheißung ist in jeder Hinsicht anders.
Ein Deferred ist ein singulärer temporaler Setter. Es ist das Duale einer Verheißung und erlaubt es, einen Wert ähnlich wie ein Versprechen es zu bekommen, zu setzen.
Ein Reader (häufiger Observable genannt) ist die Mehrfachversion eines Versprechens und die zeitliche Version eines Iterablen. Es repräsentiert mehrere Werte, die zeitlich kommen. Es ist wie ein Versprechen, das seinen Wert ändern kann.
Ein Wert , eines der am häufigsten verwendeten und primitivsten Dinge ist die synchrone Version eines Versprechens.
Wenn Sie etwas wollen, das in allen dreien nicht mit einem Versprechen vergleichbar ist - Sie brauchen etwas fortgeschritteneres. Ein Generator ist die Umkehrung eines Versprechens in dieser Hinsicht, es ist ein räumlicher, mehrwertiger Setter. Es ist das Gegenteil von einem Versprechen in jeder Hinsicht.
Sie sprechen jedoch von etwas, das in beiden Punkten asynchron ist. Sie möchten etwas, das verfügbar / nicht verfügbar ist und den Wert ändert . Das ist ein Async-Generator, einer der komplexeren Typen, die hier gespielt werden.
Ihr Typ muss einem Generator ähneln, der zweimal async ist. Sobald Sie den nächsten Wert und einmal den Wert selbst erhalten haben, habe ich eine ähnliche C # -Frage hier . Hier ist ein interessantes Gespräch und Vortrag darüber .
Grundsätzlich möchten Sie einen Generator, dessen Werte und next() asynchron sind. Es ist ziemlich komplex und es gibt wenige Dinge, die es richtig modelliert (zum Beispiel - ein unendlicher Bildlauf, bei dem sowohl der Bildlauf als auch der Inhalt asynchron sind).
In gewisser Weise signalisiert die Sequenzendung, dass Ihr Wert "nicht mehr verfügbar" ist, und die Sequenz, die die nächste Instanz erzeugt, zeigt an, dass Ihr Signal nicht mehr zeitweise verfügbar ist.
Ich empfehle auch Erik Meijers Rede und Kris Kowals GTOR zu diesem Thema.
Ein Versprechen ist ein geordnetes Tripel:
%Vor%Seine Umkehrung muss auch ein geordnetes Tripel sein:
%Vor%Sie möchten jedoch nicht benachrichtigt werden, wenn der Wert beginnt zu verfallen, was sofort der Fall ist; Stattdessen möchten Sie benachrichtigt werden, wenn der Wert verfallen ist.
%Vor% Benachrichtigung enthält Dispose Semantik. Eigentlich wäre es sehr ähnlich zu IDisposable , wenn es als IDisposable<T> definiert wäre.
Es sieht aus wie ein Frankenstein-Hybrid von Task<T> und IObservable<T> .
Das asynchrone Dual von IDisposable vielleicht?
Du hast 'scala' in deinen Tags erwähnt, also: auf jvm kann es als weiche / schwache Referenz gemacht werden. Sie können dieses Konzept auf andere Technologien portieren, müssen aber selbst die Speicherverwaltung übernehmen. aber es passt besser zu einzelnen Werten als zu Streams
Tags und Links scala language-agnostic haskell frp promise