11115 - DOM Collection JS classes should delegate to Array.prototype

Status: VERIFIED WONTFIX

(Core :: DOM: Core & HTML, defect, P3)

Description

[Brendan Eich [:brendan]]

Vidur kindly said file a bug on him, but I figured I could do this with his
advice and consent, so I'm filing it on me!

/be

Comment 1

[brendan-obsolete]

I should keep my bugs assigned to [e-mail], not to my @mozilla.org
alter ego.

/be

Comment 2

[Henrik Gemal]

Why update on this one?

Comment 3

[Henrik Gemal]

I meant "any update on this one?" Ups!

Comment 4

[ckritzer (gone)]

Any testcase?

Comment 5

[Henrik Gemal]

What about something like this:
<SCRIPT>
for (a in document.getElementsByTagName("*")) {
  document.writeln(a + "<BR>");
}
</SCRIPT>

Comment 6

[Brendan Eich [:brendan]]

Henrik: the advantage of making DOM collection classes delegate to
Array.prototype is that one could then use slice(), concat(), join(), and all
the other Array methods on collection instances.

/be

Comment 7

[Brendan Eich [:brendan]]

Moving out.

jst, vidur: is this kind of extension (it gives all DOM collections methods such 
as sort and slice/splice) allowed by the standard?

/be

Comment 8

[Brendan Eich [:brendan]]

[e-mail] wrote:
> I say WONTFIX. One reason for this is that there are a number of different
> array type interfaces in the DOM but not all of those can support things like
> soring, take the attributes list (NamedNodeMap) in all nodes for instance,
> attributes is a completetly unorderd list. The attribute nodes in that list
> are accessible by index, but there's no way to insert an attribute node into
> that list at a particular index. If we do choose to support things like sort
> in all our array like interfaces we'd need a way for the JS engine to tell
> the native (C++) implementation to either do the sorting or the native
> implementations would need to expose the neccessary methods (through internal
> interfaces) for the JS engine to do the sorting, right?

Right.  Array.prototype.sort is generic, it uses only OBJ_GET_PROPERTY (which 
for native objects will call the JSClass.getProperty hook) to put array values 
in a vector, sort them, and then reinitialize the this parameter as a new array 
object with the sorted vector as its content (that re-initialization uses 
OBJ_DEFINE_PROPERTY, which for native objects will call through the addProperty 
JSClass hook).

So the DOM classes would have to have non-permanent (deleteable) properties, and 
they would have to "do the right thing" given addProperty calls that replace 
existing indexed properties with new ones having different (sorted) values. 

I'll WONTFIX this bug, thanks. 

/be 

Comment 9

[Henrik Gemal]

Just so I understand:
for (a in document.getElementsByTagName("*")) {
  document.writeln(a + "<BR>");
}
will never be possible?

Comment 10

[Brendan Eich [:brendan]]

Henrik: your for..in loop example has nothing to do with this bug.  If it does
not work as you expect, please file another bug saying that indexed elements of
DOM collections are not enumerable (lack JSPROP_ENUMERATE in their JS property
attributes).  If it works, then where's the beef?

/be

Comment 11

[Jan Carpenter]

Mass update of qa contact

Comment 12

[Jan Carpenter]

verified