Mark Roberts wrote:
Wanting something value-ish, featureless, monadic, is a good goal
for a differently named abstraction built on value objects.
Promises are not that abstraction. Do the work to show the win,
under a new name (Future?).
I believe the win has already been shown, though: "Futures" would of
course give you the same thing Promises do while supporting those
additional use cases where you don't want recursive unwrapping.
No. Future as a featureless value object would not have any of the
identity-based problems reference types including Promises have. It
would become its result when fulfilled. You would not be able to do much
with a Future other than "then" it. There would be no thenable
assimilation via duck-typing of thenables.
#2: combinators such as .all do not use .chain, they use .then
Is this such a big deal? If you have .chain then you have .then, so
you can certainly "have it all".
That .then would be based on .chain is irrelevant. Anyone using .all
would not get .chain and would potentially depend on all the .then
magic. Purists trying to use only .chain would need to write their own
.chainAll, etc., which would not be in the standard.
Imagine we simplified to do just .chain and .cast, and combinators
called .chain. We'd be breaking compatibility with extant promises
libraries
IMO, leave .all and the rest of the combinators as they are using
.then. I would not mind so long as .chain is intact.
See above. This does not wash unless you aren't using combinators at
all, or you are rolling your own -- in which case we have a bloated "do
both" forked standard.
/be
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
