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. 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 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. David [1] http://dom.spec.whatwg.org/#concept-resolver-resolve [2] http://casperjs.org [3] http://casperjs.org/api.html#casper.then [4] https://github.com/laurentj/slimerjsReceived on Tuesday, 23 April 2013 08:54:55 UTC
This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:12 UTC