- From: Cameron McCormack <cam@mcc.id.au>
- Date: Mon, 24 Oct 2011 11:57:56 -0700
- To: Jonas Sicking <jonas@sicking.cc>
- CC: Aryeh Gregor <ayg@aryeh.name>, Julien Richard-Foy <julien@richard-foy.fr>, public-webapps@w3.org
On 24/10/11 11:51 AM, Jonas Sicking wrote: > 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. Yes. > For case 3 I think we should simply return an Array. No need for > anything more magic than that. Agreed. > 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? Yes that is the hope. I should run through the mutation function definitions just to be sure. :) It is at least well defined. An alternative is to introduce a new prototype object in between Array.prototype and the mutable array-like object that has properties shadowing all of the mutating functions with a function that unconditionally throws. I would prefer to avoid having to update the spec whenever new Array.prototype methods are introduced in the ES spec if possible, though.
Received on Monday, 24 October 2011 18:58:34 UTC