On Tue, Apr 23, 2013 at 4:54 AM, David Bruant <bruant.d@gmail.com> 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. 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. Hopefully not -- it's really very simple for Promises/A+ libs to add `then` to the Promise prototype. 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 :PReceived on Tuesday, 23 April 2013 12:57:26 UTC
This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:12 UTC