- From: <bugzilla@jessica.w3.org>
- Date: Sun, 05 Oct 2014 06:10:24 +0000
- To: public-script-coord@w3.org
https://www.w3.org/Bugs/Public/show_bug.cgi?id=23682 --- Comment #28 from Jonas Sicking <jonas@sicking.cc> --- Thanks for working on this! I should note that I'm still passing this proposal around to interested parties. While no one has yet found horrible broken-ness in it, not everyone has express full confidence yet. (In reply to Cameron McCormack from comment #25) > For the syntax, I think we should avoid trying to make sequence<> be more > like an object reference type. Let's stick with it meaning a copy-by-value > sequence of values. I don't care strongly, but it does seem a bit inconsistent to me to use different types to indicate if we always get back a freshly created object, or if we potentially get back the same object multiple times. Especially given that we already have [NewObject] to cover exactly that. Also, sequence<> means "any iterable object" which is a bit of a weak assertion here, since we know we'll always return an Array and not just something iterable. I think using "Array<T>" and either "frozen Array<T>" or "FrozenArray<T>" would keep separation of concerns better. But like I said, I don't care strongly about what WebIDL syntax is used. > The only thing this doesn't cover is an enforcement of say > Navigator.gamepads not changing value in the one script turn. Management of > the Array reference that gamepads holds is up to that spec. I guess it's > enough to just say "queue a task to update Navigator.gamepads to value > blah."? Yes. I don't think this is any different from any other property. Specifications are responsible to not break run-to-completion or expose thread safety issues. This is done by making sure to only change what properties or functions return in response to explicit API calls or in between "turns". -- You are receiving this mail because: You are on the CC list for the bug.
Received on Sunday, 5 October 2014 06:10:27 UTC