[whatwg] Adding ECMAScript 5 array extras to HTMLCollection

[Garrett Smith]

On 8/2/10, Garrett Smith <dhtmlkitchen at gmail.com> wrote:
> On 8/2/10, Oliver Hunt <oliver at apple.com> wrote:
>>
>> On Aug 2, 2010, at 7:36 AM, And Clover wrote:
>>
>>> On 07/30/2010 06:43 AM, Oliver Hunt wrote:
>>>> all array functions defined in ES5 are "generic" in that they work
>>>> over any array-like object.
>>>
>>> They're guaranteed to work over any array-like native JavaScript object.
>>> They're *not* guaranteed to work on host objects like the various node
>>> lists.
>>
>> Uhhh, I have no idea what you're talking about -- there are no type
>> checks
>> in any of the array prototype functions, they all operate in terms of
>> property access alone, all the methods we're talking about basically
>> start
>> out like this:
>>
>
> [..]
>
> And they continue like this:
>
> "Whether the [something] function can be applied successfully to a
> host object is implementation-dependent."
>
> Where "[something]" is replaced by "slice" in this case.
>
>> Eg. "array-like" in the context of ES5 should be interpreted as "has a
>> property named 'length', the array methods will work on any type.
>>
>
> That is not true. ECMAScript has what is called "host object". A host
> is any ecmascript object that is not defined by the specification; it

Should be:
any object that is not defined by the specification.

I also linked to the old "catchalls" proposal earlier in the thread.
That is because the host objects mentioned here have a specialized
"catchall" behavior that isn't yet defined by any specification, so
when the code has property access with an integer index, as: anObj[2]
- then it's supposed to be the same as a  call to the `item` method.
That mostly works, but isn't specified isn't completely and isn't
completely interoperable due to variance in undefined vs null.

I noticed that rather than define catchall, HTML5 copied the old DOM text:

| In the ECMAScript DOM binding, objects implementing the
| HTMLFormControlsCollection  interface must support being
| dereferenced using the square bracket notation, such that dereferencing
| with an integer index is equivalent to invoking the item() method with that
| index, and such that dereferencing with a string index is equivalent to
| invoking the namedItem() method with that index.

The problem with that is that property access doesn't do any
typechecking, and so
  obj[2]
 - is equivalent to:-
  obj["2"]

Can it be argued as to what "integer index" means? And what is a "string index"?

Garrett