Le 23/04/2013 14:56, Dean Landolt a écrit :
On Tue, Apr 23, 2013 at 4:54 AM, David Bruant <[email protected]
<mailto:[email protected]>> 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.
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.
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.
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.
David
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
