A Challenge Problem for Promise Designers (was: Re: Futures)

David Bruant 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, 
> which
> (2) implies that there is to be no implicit lifting or flattening in 
> .then. 
> 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 [1]) 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).



[1] http://casperjs.org/api.html#casper.then

More information about the es-discuss mailing list