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
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
