- From: <bugzilla@jessica.w3.org>
- Date: Fri, 14 Mar 2014 02:34:27 +0000
- To: public-script-coord@w3.org
https://www.w3.org/Bugs/Public/show_bug.cgi?id=25048 --- Comment #5 from Domenic Denicola <domenic@domenicdenicola.com> --- > Or to put this another way: are there any use cases for allowing attributes of Promise type at all? For sure! See all the usage in [1] or [2]. Or, the recently-proposed loaded/ready promises could easily be attributes, if not for the fact that most of those resources allow you to reload them (e.g. by setting `.src` again). > The most common practical source of exceptions is if you .call() the getter function on a wrong kind of object. This should return a rejected promise for the same reason; if you are using a getter representing an asynchronous result, you should expect to be able to do asynchronous error handling. > Hmm, what if you had an IDL attribute of a Promise<T> type that throws when assigning? Yeah, this is trickier to reason about---mainly because I don't know of a reasonable use case for promise attributes with setters. I assume there'd be coercion behavior, so e.g. for a Promise<long> attribute these would be fine: foo.bar = 5; foo.bar = Promise.resolve(5); but these would not: foo.bar = {}; foo.bar = Promise.resolve(function () { }); I would probably again argue that the result should be `foo.bar` set to a promise rejected with a `TypeError`, since people would access the result of the set via foo.bar.then(processValueRepresentedByBar, couldNotGetValue); and would be surprised if they had to write try { foo.bar.then(getValueThatWasSet, couldNotGetValue); } catch (e) { couldNotGetValue(e); } [1]: https://github.com/whatwg/streams [2]: https://rawgithub.com/ClaesNilsson/raw-sockets/gh-pages/index.html#interface-tcpsocket -- You are receiving this mail because: You are on the CC list for the bug.
Received on Friday, 14 March 2014 02:34:29 UTC