A Challenge Problem for Promise Designers (was: Re: Futures)
bruant.d at gmail.com
Fri Apr 26 07:13:19 PDT 2013
Le 26/04/2013 15:47, Claus Reinke a écrit :
> My own argument is not for nested futures themselves, but (1) for
> futures to offer the same interface (.of, .then) as other thenables,
> (2) implies that there is to be no implicit lifting or flattening in
> For promises, I don't expect to use nested promises much, but I do
> expect to define and use thenable methods that should work for
> promises, too.
I see. So the underlying problem is the assimilation problem. If any
object with a 'then' method is considered as a promise, then non-promise
values with a 'then' method (that are not supposed to exist according to
Promise/A+, but do anyway in real life ) will be mistakenly unwrapped
if flattening semantics is the default...
I was in the naive belief that assimilation and flattening semantics
were disjoint problems :-) Sorry about that.
If I suggest giving up on thenable, Domenic and others are going to
starting throwing rocks at me, so I won't do that :-) Instead:
(messed up) idea: a unique symbol to denote that a value is *not* a
promise. Useful for the flattening semantics to know when to stop *even*
if there is a 'then' method (which is admittedly a rare case anyway and
can justify the use of a specific symbol).
More information about the es-discuss