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


--- 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

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