Re: Futures

Le 23/04/2013 14:56, Dean Landolt a écrit :
> On Tue, Apr 23, 2013 at 4:54 AM, David Bruant <bruant.d@gmail.com 
> <mailto:bruant.d@gmail.com>> wrote:
>
>     Le 22/04/2013 19:32, Dean Landolt a écrit :
>
>         I was just saying there will be pressure to include support
>         for thenables (already in DOMFutures). If you believe
>         otherwise don't let me dissuade you -- I would absolutely love
>         it if I were proven wrong!
>
>     I guess it would take making sure no content can be confused by
>     the current steps 3-5 of the current resolve spec [1]. I believe
>     browser vendors have tools to study this kind of things.
>
>     CasperJS [2] create objects with a then method [3]. Interestingly,
>     this doesn't run in the browser (until someone decides to
>     re-implement it of top of a web browser or FirefoxOS. [4] ?).
>     Potentially more interestingly, Casper objects could be promises
>     subclasses (to be considered).
>     It wouldn't be surprising if there were content on the web where
>     the promise subclass trick couldn't work.
>
>
>
> What do you mean by the promise subclass trick? If you mean that 
> Casper instances would subclass Promise I don't think that'd work out 
> too well as is. Promises/A (and I presume A+) intentionally specified 
> `then` to return a new promise, so Casper would have to change in a 
> very breaking way to pull this off.
I'm not sure it would be a breaking change for the vast majority of 
people. They may actually like that instead of being forced to to 
casper.start. They may also enjoy being able to chain .then-s. But maybe 
it's breaking.

Anyway, my point was that there exist libraries in which "then" is a 
function and the object with this function isn't a promise. These 
libraries will end up in a terrible confusion when used with Futures.
You think you're resolving a future with an object and... oops! the 
built-in Future algorithm confused your object for a promise. Suddenly, 
not only are you not resolving your promise with the value, but your 
.then method is called unexpectedly.

>
>     In any case, considering that an object with a 'then' function is
>     a promise is a recipe for confusion. Promise/A+ folks asked for
>     and are happy about it. The rest of the webdevs who aren't aware
>     of this subtle non-intuitive rule will have a very hard time when,
>     for whatever reason, they have a 'then' function in a resolve
>     value and their code really behaves in a way they don't understand.
>
>
> I agree it's a recipe for confusion. But the weight of legacy code 
> (growing by the day) may be too much to bear.
What about the weight of legacy non-promise code using "then"? The best 
thing we can say now is that we know nothing about it and it'd be wise 
to wait until more data on "then" is available. The Casper example 
should at least worry us. I hope it will be the browser vendors choice.

> Hopefully not -- it's really very simple for Promises/A+ libs to add 
> `then` to the Promise prototype.
Aren't they already doing that? I don't understand your point here.

>
>     I don't think in the entire platform there is a precedent of doing
>     this (maybe for a good reason?). We'll see what web browsers end
>     up implementing.
>
>
>
> IMHO __proto__ is one precedent -- and we know how that's going :P
Once again, __proto__ is not a good comparison. It's already in the 
platform. As far as promises are concerned, the platform has exactly no 
obligation to follow the current Future or an alternative that'll emerge 
tomorrow; no obligation to follow Promise/A+ or whatever else.

David