Re: A Challenge Problem for Promise Designers

On Fri, Apr 26, 2013 at 9:36 AM, David Bruant <bruant.d@gmail.com> wrote:

> Le 26/04/2013 14:54, Kevin Smith a écrit :
>
>> What exactly is the controversy here?
>>
>> I think we all agree with the semantics of "then" as specified in
>> Promises/A+.  (If not, then we have a really big problem!)
>>
>> If so, then the only real controversy is whether or not the API allows
>> one to create a promise whose eventual value is itself a promise.  Q does
>> not:  it provides only "resolve" and "reject".  DOM Futures do by way of
>> "Future.accept".  As far as I know, there's nothing about Q's
>> implementation that would make such a function impossible, it just does not
>> provide one.
>>
> I believe at this point the question isn't so much "can I build a promise
> for a promise?", but rather "what should be the default Future semantics?"
> Namely:
>
>     Future.accept(5)
>         .then(function(x){
>             return Future.accept(x);
>         })
>         .then(function(y){
>             // is y a Future?
>         })
>
> I'm arguing in favor of y being guaranteed to be a non-Future value. It is
> my understanding others would want y to be a Future.
> That would be the controversy as I understand it.
>


Reframing this in terms of resolution semantics may be helpful. I think
others would want a way to resolve one promise without recursively
resolving them all. That doesn't mean that the default resolution semantics
can't recursively resolve. Recursive resolve can be built on top of a
single-step resolver, but even so, it would be useful to also provide (and
recommend) recursive resolve resolve since it has the resolution semantics
demanded by the vast majority of use cases.

The fundamental controversy, as Juan just noted, is how to precisely
identify a promise in order to do either of these two things. This problem
isn't quite so clean cut, but it's much more important to solve. I've been
trying to bring some attention to it over the last few days -- I hope it's
clear that a `then` method is not enough to identify a promise language
construct -- this will subtly break existing code (e.g. casperjs).

In passing people keep assuming a well-known symbol could solve this
problem, but haven't offered any ideas for compatibility with es5 code. I
can't see how we could shim enough of the module system to use it as a
registry here, but maybe we could hang a symbol of a built-in Promise class
that could be shimmed as a random string. Given a built-in Promise class I
believe an `instanceof` branding could be made to work in a shimmable
manner too, with __proto__ hacking getting you the rest of the way there if
it really comes to it (es5 cross-frame wackiness, for instance).