Re: Futures

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

>  Le 23/04/2013 15:27, Dean Landolt a écrit :
>
>
>>
>>> 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.
>
> Until it is widely deployed, *everything* is possible. What browsers will
> choose/accept to implement will be the standard.
> And indeed, I believe existing libs could adapt easily to platform Futures
> even if these don't follow Promise/A+.
>

 True.


>   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 :)
>
> Oh I see. Then yes, in that sense __proto__ is a relevant comparison
> (sorry for the misunderstanding). Though, the confusion for __proto__ is
> less likely because first, most people were aware of it (which really isn't
> clear for promises/A+) and __ is the sign for both "be careful" and "it's
> unlikely to collide with something else" which isn't the case for "then".
>


Agreed. And now that it looks like only the unquoted version of __proto__
will be special the analogy pretty much falls apart in es6. Which is
awesome.