W3C home > Mailing lists > Public > public-webapi@w3.org > May 2006

Re: ACTION-87: Selectors API

From: liorean <liorean@gmail.com>
Date: Sat, 13 May 2006 23:40:06 +0200
Message-ID: <cee13aa30605131440y1ee7914pd72bbe17d75d29bf@mail.gmail.com>
To: "Web APIs WG (public)" <public-webapi@w3.org>

On 13/05/06, Anne van Kesteren <annevk@opera.com> wrote:
> On Sat, 13 May 2006 21:08:26 +0200, liorean <liorean@gmail.com> wrote:
> > And StaticNodeList looks to me to be pretty array-like.
>
> Well, if StaticNodeList looks that way NodeList would look that way too
> and I'd therefore suggest raising that on www-dom@w3.org instead. Note
> that I don't really want to be defining StaticNodeList in the first place.

Not quite. NodeList are, in some ways, array-like. But StaticNodeList
is more array-like, for several reasons:

- First of all, I think StaticNodeList would be implemented as an
actual list or hash table, not as filters used on the live node tree.
This specifically because it's not supposed to be affected by changes
in the node tree. This means they are considerably different under the
hood.

- Second, manipulating the DOM using elements gotten from looping
through a NodeList will have effects on that NodeList during the loop.
Removals, reparentings, insertions etc, may affect the NodeList.
StaticNodeList will not be affected by changes to the DOM. This means
the different mapping functions may have very bizzarre side effects on
NodeLists that they would not have on StaticNodeLists.

- Third, NodeLists being live means you cannot manually manipulate
them. StaticNodeLists don't have this problem. Since they are not
live, manipulation of them should not be a problem. This means array
functionality such as sort, push, pop that would simply not make sense
on a NodeList would make perfect sense on a StaticNodeList.




I do see two notable differences between StaticNodeList and ECMAScript
Array though:

- NodeList is naturally dense, so StaticNodeList would have to force
denseness too. Array is sparse. This means that what happens when the
user tries assigning to random indices larger than the length; or
removing elements in the middle of the StaticNodeList; or setting the
length to a value larger than the current length; would need to be
defined in a way that makes sense in the ECMAScript bindings.

- NodeLists only contain Node objects, so the same would have to be
true for StaticNodeList. Arrays may contain any type of JavaScript
object. This means what happens if the user tries to add a non-Node
object to the StaticNodeList would have to be defined in the
ECMAScript bindings.


One possible solution to these problems:
- If trying to insert a non-Node in the StaticNodeList, throw the
appropriate RunTime error.
- If trying to delete any index smaller than the length of the
StaticNodeList, throw the appropriate RunTime error. (might have to be
length-1, to allow for removing the last element in StaticNodeList)
- If trying to assign to an index larger than the length of the
StaticNodeList, thow the appropriate RunTime arror.
- If trying to assign a value larger than the current length of the
StaticNodeList to the length property, throw the appropriate RunTime
error.
-- 
David "liorean" Andersson
<uri:http://liorean.web-graphics.com/>
Received on Saturday, 13 May 2006 21:40:20 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 8 January 2008 14:18:55 GMT