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


--- Comment #22 from Cameron McCormack <cam@mcc.id.au> ---
Thanks for pushing this issue forward again Jonas.

I don't have a strong opinion on whether frozen objects is something we should
be using or avoiding, although I will point out that Gecko already does use
frozen arrays for Gamepad.{button,axes} and navigator.languages, and these are
currently shipping.

I have a couple of concerns with the Array+observing pattern.

One is that we will have different patterns for exposing mutable lists of
values and mutable sets and maps of values.  In bug 26183 there is some
discussion about how to expose iterators for Set-like and Map-like objects with
additional behaviour, and I think that a natural extension of that would be to
allow IDL interfaces to be declared as "map-like" or "set-like" to gain the API
surface of the built-in Maps and Sets, but which can respond to
insertions/removals, checking objects before they're inserted, etc.  (I am
thinking that is the most workable solution for what to do with what to do
about http://dev.w3.org/csswg/css-font-loading/#FontFaceSet-interface.)

What I'm wondering is why we should have this plain Array object + observing it
pattern when we have a list of values, while having Set-like and Map-like
objects for those types?  Why not have an Array-like object that feels the same
yet can have the additional behaviour?  An argument against is that such
objects would need to exposed indexed properties and most people want to avoid
new objects that do that (although it is simple enough to do with a Proxy). 
One difference between Arrays and Sets/Maps is that you can observe the former
but not the latter, since the latter manipulate some state internal to the
object that you can't observe.

A second concern is that observing the Array changes means that (a) you need to
wait until the callbacks have been invoked after going through the event loop,
which means that you can't have any immediate reactions to the changes to the
list, and (b) that you have to deal with invalid values in the Array (and
holes) asynchronously, which means that you can't throw to provide author
feedback that they've manipulated the Array incorrectly.

As for the "feels like JS" or "would be what a script library would do", I
don't feel yet like any of the solutions we have so far really fit into these

You are receiving this mail because:
You are on the CC list for the bug.

Received on Monday, 29 September 2014 22:26:58 UTC