[whatwg] Adding ECMAScript 5 array extras to HTMLCollection

[Garrett Smith]

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?

The externally observable behavior wouldn't have to change.

[[HasProperty]] checks (using `in`) with catchalls have sometimes
unexpected results, so I wouldn't want to see that kind of change.

Try some of the tests here:
<http://jibbering.com/faq/names/extra_props.html>

The article needs a little updating but the examples I'm referring to
demonstrate disparity with `in` operator:
FF3.6
  'test' in this.form true
  'test' in this.form.elements false

A catchall should possible for a result of `null` for indexed access.
This probably isn't adding any value over returning `undefined`
because many implementations will result `undefined` for property
access and most programs won't care one way or the other (and if they
do, they're not interoperable with existing browsers).

I want the specs to codify behavior of existing various collections
and to do that, I want to figure out where and why catchall is used.

I can't answer as to why Gecko uses a catchall; perhaps some of the
Mozilla devs on this list can give further info. Perhaps there is
behavior for "past names map" that requires catchall (I don't think
anybody is a big fan of past names map).

The only change I can see
> would be the loss of the host object exceptions in the ES spec, but that
> just puts you in the position of having semantics that match the current
> host object behavior in those implementations that already allow array
> functions to operate on host objects.
>

The semantics for native object are defined by ECMA-262.

If collection is required to be implemented as a native ECMAScript
object, then it would still be considered a host as a native object,
would be indistinguishable from other native objects, both internally
and externally, and so would not be subject to ES "whether or not the
xxx method may be applied to a host object" loopholes. Thus,

  [].slice.call( ho )

could be expected work. It would have to work because
Array.prototype.slice would have no way of determining that `ho` is a
host object; it would simply see that it is passed in a native object.
It would not be able to differentiate or discriminate between that and
a user-defined object.

All that would be necessary to make that happen would be to state that
the collection -- NodeList, for example -- is implemented as a native
ECMAScript object. That alone would be enough to guarantee that any
native operation would have results that could be expected.

Again, from ES point of view, there are two types of host objects:
1) host object implemented as a native object
2) host object implemented with other semantics

Garrett