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: Jonas Sicking <jonas@sicking.cc>
Date: Mon, 24 Oct 2011 11:51:21 -0700
Message-ID: <CA+c2ei_32aQnMigN_aB-Bk5Y5tXwUv9=xDiSUk_KOPTjwsisDQ@mail.gmail.com>
To: Cameron McCormack <cam@mcc.id.au>
Cc: Aryeh Gregor <ayg@aryeh.name>, Julien Richard-Foy <julien@richard-foy.fr>, public-webapps@w3.org
On Mon, Oct 24, 2011 at 11:17 AM, Cameron McCormack <cam@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
Received on Monday, 24 October 2011 18:52:28 GMT

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