[Bug 23682] Fix the current [ArrayClass], [] and sequence<T> mess

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