liorean wrote:
On 13/05/06, Anne van Kesteren <[EMAIL PROTECTED]> wrote:
On Sat, 13 May 2006 21:08:26 +0200, liorean <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED] 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 don't want us to define a new array when ECMAScript has a perfectly
good one. That is just a lot more work for everyone involved.
What we could maybe do though is to return a real ECMAScript array. I
actually like this idea a lot since that'll integrate much better with
scripts than a StaticNodeList would.
We could define a new top-level object like DOMArray and then let that
map to different things in ECMAScript and Java.
/ Jonas
