Re: Futures

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

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

David