Visto che c'è un aumento nelle soluzioni basate su attori, sono un po 'confuso riguardo alla mancanza di lib di F # che usano qualcosa come il MailboxProcessor come API.
Qual è il lato negativo?
Perché gestire le capacità limitate e il sovraccarico dei wrapper?
Esistono API F # che utilizzano un agente come API di prima classe invece dei dettagli di implementazione?
Sto parlando della concorrenza non bloccante con gli desiderati scenari di effetti collaterali. Soprattutto i casi in cui una lib usa già qualcosa come MailboxProcessor sotto il cofano, ma definisce i wrapper attorno al protocollo di comunicazione (che potrebbe essere ben definito con DU).
Immagino che il messaggio che passa in alto sia nell'occhio di chi guarda, ma penso che Erlang e Scala dimostrino che il funzionale va di pari passo con gli attori. Esistono anche implementazioni Haskell, quindi non è una questione di purezza, ma piuttosto di stile.
Quando dico che i wrapper sono vincolati, intendo:
-
duplicazione del protocollo (wrapper + messaggistica sottostante). Va bene se tutto ciò che esponi è un metodo, ma spesso non lo è.
-
duplicazione esplicita delle funzionalità (fire-and-forget, async con risultato, sincronizzazione, ecc.). Coprendo ogni possibilità con un wrapper risulterebbe un'API inutilmente gonfia, mentre non coprendola - in realtà rimuoverà la capacità.
-
set di verbi non standard, che riduce la capacità di comporre.
Supponendo che non siate contrari agli attori in linea di principio, quali sono i lati negativi dell'utilizzo di MailboxProcessor come API standard per implementazioni che coinvolgono la concorrenza non bloccante?