Re: Futures

On Tue, Apr 23, 2013 at 9:12 AM, David Bruant <bruant.d@gmail.com> wrote:

>  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> 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.
>

IIRC you can already chain thens -- the break is that you will be forced to
chain thens in order to maintain your intended chronology. Inheriting from
Promise would suggest all those then calls will be fired in parallel
instead of happening in serial.

Although the only time I tried Casper (~ a year ago) I gave up on it
because I couldn't get this stuff right anyway.


>  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.
>

Apologies, I wasn't very clear. I completely agree with this point and was
just trying to reinforce it :)

>
>
>> 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.
>

No, DOMFutures ships with this OOTB. If there were an es Promise or Future
builtin I suspect there would be a lot of pressure to specify it with
`then` on the prototoype to make its instances compatible with existing
Promises/A+ libs. That's the crushing weight of legacy I'm referring to.

What occurred to me is that it really is just a few lines of code for each
of these Promises/A+ libs to add to tack on the prototype `then` without
having to muddy the spec. In hindsight this seems obvious. I wonder why
DOMFutures didn't go this route? It may not be too late.

>
>  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.
>

You said "I don't think in the entire platform there is a precedent of
doing this". I assume by "this" you meant using a forgeable string key that
could lead to confusion. That is what we were discussing, right? If so I
think __proto__ is a great example. And again, I think it helps make your (*
our*) point :)