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).
Thoughts?
David
[1] http://casperjs.org/api.html#casper.then
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
