Jaka jest różnica między przyszłością a obietnicą?

Jaka jest różnica między przyszłością a obietnicą? (W Akka i Gpars.)

Wyglądają dla mnie tak samo, jak blokują i zwracają wartość przyszłości, gdy wywoływany jest get, a obietnicą jest uzyskanie wyniku przyszłości.

Porozmawiam o Akka / Scala, ponieważ nie znam Gpars ani Akka / Java.

W Scali 2.10, która obejmuje odpowiednią część Akka w rozkładzie standardowym, a Futurejest zasadniczo tylko do odczytu odniesieniem do wartości, która ma być jeszcze obliczona. A Promisejest prawie takie samo, z tym, że możesz do niego również pisać . Innymi słowy, możesz czytać zarówno Futuresi jak i Promisesi, ale możesz pisać tylko do Promises. Możesz uzyskać Futureskojarzenie z Promisewywołaniem futuremetody na nim, ale konwersja w innym kierunku nie jest możliwa (ponieważ byłoby to nonsensowne).

Według wikipedii są to te same pojęcia:

W informatyce przyszłość, obietnica i opóźnienie odnoszą się do konstrukcji używanych do synchronizacji w niektórych współbieżnych językach programowania. Opisują obiekt, który działa jak proxy dla wyniku, który początkowo jest nieznany, zwykle dlatego, że obliczenie jego wartości jest jeszcze niepełne.

Niektóre biblioteki mogą nazywać je w jeden sposób, inne mogą nazywać je w inny sposób. I za każdym razem mogą być wdrażane w różnych smakach. Niektóre biblioteki mogą używać tych synonimów do rozróżniania różnych smaków. Chociaż twierdzę, że jest to zły wybór (ponieważ ewidentnie myli ludzi), ten link sugeruje, że w Scali jest to powszechna praktyka.

Jak sugerował Płomień @ Ptharien, w Scali a Futurejest operacją tylko do odczytu, a a Promisedaje możliwość uzyskania wyniku (lub niepowodzenia) dla operacji, którą reprezentuje.

A Promisejest zatem najlepiej używany przez kod odpowiedzialny za przeprowadzenie operacji w celu propagacji wyniku, podczas gdy a Futuresłuży do ujawnienia go kodowi klienta, który z kolei będzie oczekiwać na wynik. Ale znowu, proszę zauważyć, że to rozróżnienie jest specyficzne dla Scali i może mylić osoby postronne.

Dodam trochę tutaj, ponieważ ostatnio pracuję z wieloma futures na Javie, ale mam również doświadczenie w rozwoju Scala / Akka. Ta odpowiedź w większości powieli to, co zostało powiedziane, ale zwróci uwagę na mnogość implementacji, które są dziś powszechnie używane w JVM.

Po pierwsze, oryginalny plakat wspomina o używaniu get i blocking - nigdy nie rób tego poza testami.

Kiedy uczę koncepcji FP i współbieżności w mojej obecnej roli, najpierw mówię uczniowi, że semantycznie obietnice i futures są synonimami, ponieważ jako konsument obietnicy lub przyszłego interfejsu API, programista nie musi rozumieć, że są lub JEŚLI są różnice semantyczne - tylko mechanika radzenia sobie z nimi bez blokowania IO.

Stwierdzenie, że przyszłość nie może zostać ukończona i że obietnica może (np. Jak na scala / akka / play apis) jest zbyt uproszczone:

Niektóre kontrakty futures można skompletować Java8 teraz wprowadza CompletableFuture do biblioteki standardowej.

Niektórych obietnic nie można zrealizować Podobnie, w interfejsie API obietnicy Play obietnicy nie można spełnić, ale można ją wykorzystać, dlatego gra wprowadza inny semantyczny - nawet pod parasolem Typesafe. Ponadto API promise Play może konwertować ze skalami futures w obu kierunkach - (F.Promise.wrap (przyszłość) lub promise.wrapped ()).

Pracując z technologią Typesafe na Java8, często będziesz przechodził między kontraktami futures / obietnic po prostu dlatego, że jeden interfejs API jest lepszy (Play Promise API wydaje się lepszy w przypadku lambda Java8). W Akka + Play + Java8 będziesz przyjmował od aktorów kontrakty i zawijał je w obietnice, komponował callbacki i zwracał je od kontrolera.

Tak więc, jak mówię ludziom, kiedy nauczam, obietnice i futures są mniej więcej synonimami.