Re: [selectors-api] Return an Array instead of a static NodeList

On Mon, Oct 24, 2011 at 11:57 AM, Cameron McCormack <cam@mcc.id.au> wrote:
> 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.

Based on my testing, many methods wouldn't throw for zero-size
array-like objects. Similarly, methods like .push(), .unshift() and
.slice() wouldn't throw if no entries were actually requested to be
added or removed. And .reverse() wouldn't throw for single-sized
array-like objects.

May or may not be a big deal though.

/ Jonas

Received on Monday, 24 October 2011 19:15:45 UTC