On Mon, Oct 24, 2011 at 11:17 AM, Cameron McCormack <c...@mcc.id.au> wrote: > On 30/08/11 4:19 PM, Jonas Sicking wrote: >> >> Indeed! I think it's already been decided that all non-mutating >> functions should be added to NodeLists and other list-like DOM >> objects. I believe Cameron is still working on the specifics of that. > > Shortly before the LC#2 was published, I added an [ArrayClass] extended > attribute that you can put on interfaces that are not defined to inherit > from another. That causes that interface's [[Prototype]] to be > Array.prototype instead of Object.prototype. It's then up to the designer > of the interface to ensure that length and array index properties behave > usefully (by defining a length IDL attribute and using indexed properties) > so that the Array.prototype methods will do nice things. > > The other construct that uses Array.prototype is platform array objects. > They too have Array.prototype as their [[Prototype]]. Web IDL defines how > array index properties and length are exposed on platform array objects so > that they work with Array.prototype methods as best they can.
I think we have three types of array-like objects: 1. Objects like the one returned from getElementsByTagName where modifications to the array just doesn't make sense. 2. Objects like the one returned from HTMLInputElements.files where modifications to the array could be allowed and where such modifications affect the DOM (i.e. the submitted value would be changed) 3. Object like the one returned from findAll where modifications don't affect anything other than the mutated object. It appears to me that [ArrayClass] helps with case 2. For case 3 I think we should simply return an Array. No need for anything more magic than that. Case 1 appears to be unaddressed though. And I actually think that's the most common case in the DOM right now. Or were we hoping that [ArrayClass] would be used there too and all mutating functions would throw? / Jonas