W3C home > Mailing lists > Public > public-webapps@w3.org > October to December 2011

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

From: Cameron McCormack <cam@mcc.id.au>
Date: Mon, 24 Oct 2011 11:57:56 -0700
Message-ID: <4EA5B534.3040302@mcc.id.au>
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 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:48 GMT