W3C home > Mailing lists > Public > public-script-coord@w3.org > April to June 2013

Re: Futures

From: Dean Landolt <dean@deanlandolt.com>
Date: Tue, 23 Apr 2013 09:44:41 -0400
Message-ID: <CAPm8pjonf3KWp8NN-c+qq_fc_W+TOScF+9cH5agdcrXCyyU55g@mail.gmail.com>
To: David Bruant <bruant.d@gmail.com>
Cc: Domenic Denicola <domenic@domenicdenicola.com>, Brendan Eich <brendan@mozilla.com>, "Mark S. Miller" <erights@google.com>, Douglas Crockford <douglas@crockford.com>, "public-script-coord@w3.org" <public-script-coord@w3.org>, Norbert Lindenberg <w3@norbertlindenberg.com>, Markus Lanthaler <markus.lanthaler@gmx.net>, EcmaScript <es-discuss@mozilla.org>
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.
Received on Tuesday, 23 April 2013 13:45:51 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:37:49 UTC