[whatwg] Adding ECMAScript 5 array extras to HTMLCollection

[Garrett Smith]

On 8/5/10, Oliver Hunt <oliver at apple.com> wrote:
>
> On Aug 4, 2010, at 6:26 PM, Garrett Smith wrote:
>
>> On 8/4/10, Oliver Hunt <oliver at apple.com> wrote:
>>>
>>> On Aug 4, 2010, at 3:32 PM, Garrett Smith wrote:
>>>
>>>> On 8/4/10, Garrett Smith <dhtmlkitchen at gmail.com> wrote:
>>>>
>>>> [...]
>>>>> "submitButton" in form.elements
>>>>>
>>>>> Existing implementations vary on when they use catchalls. I'd like to
>>>>> see standardization for this behavior and codification so that
>>>>> implementations behave similarly -- either use a catchall for a
>>>>> particular type of collection or use a native object. If a catchall is
>>>>
>>>> Native object either way, but either with a new ES catchall behavior
>>>> or with a native ES object, as specified today.
>>>>
>>>> Garrett
>>> As a question, if the node lists were implemented as catchalls, how would
>>> the behaviour differ from current NodeLists?
>>


I'll tell you, I took another peek at WebIDL and see now "getter".

The DOM, web IDL, etc should not be specifying how catchalls work;
that's an ECMAScript language feature and so it is the job for the ES
committee.

In particular, WebIDL should not use terminology "getter" because that
may be confused with the ECMAScript language construct of the same
name.

>
> So your only desire is to have NodeLists lose the host object issues?
>

That isn't very precise; I can't acknowledge that as being correct.

In this thread, I want:
 * NodeList spec'd as native ES object (DOM)
 * Static Array generics (ES)
 * Consolidate collections (DOM) to:
  -  allow [[Get]] to return undefined (not require null)
  -  use more specific terminology than "integer index" (unsigned long)
  - resolve "has" checks for collections (DOM and ES)

* Array from a NodeList can be guaranteed with [].prototype.slice.call
if NodeList is specified as a native ES object in a DOM specification
(perhaps WebIDL, as that effort seems to be continuing).

* Array Generics, as JavaScriptTM has, for a while, had Array.slice,
et al to simplify from Array.prototype.slice.call. This is something
that should be done by ES committee.

Regarding indexed collections in general, the behavior of an indexed
collection should be consolidated where possible.

"has" checks should work as expected and should not fall apart as
shown in the article.

  var form = document.forms[0];
  "0" in form; // false in Gecko
  Array.prototype.indexOf.call(form, form[0]);

Firefox: -1
Safari: 0

[...]

I have many other desires, none of them having anything to do with
this thread or programming at all.

>>  [].slice.call( ho )
>
> It sounds like all you want is for the array (and other similar) methods to
> work on NodeLists, etc but currently some implementations make use of the
> ES5 text saying the they don't need to support host objects, correct?
>
> An ES definition for the type would merely be for the purpose of removing
> the ability for an implementation to make use of the "we don't need to
> support operation X on host objects"?
>

Sorry, but I didn't understand what you meant by "the type".

I'm not proposing ES remove the text "whether or not the xxx
method..." if that's what you meant. Rather, I'm proposing that
NodeList be specified by the DOM ECMAScript bindings to be a native
ECMAScript object. That way, it will not be possible for any ES method
to discriminate against a host object.

Does that answer your question? Are there any criticism or concerns
with that proposal?

Garrett