[whatwg] Adding ECMAScript 5 array extras to HTMLCollection

[Garrett Smith]

On 8/2/10, And Clover <and-py at doxdesk.com> wrote:
> On 08/02/2010 09:57 PM, Garrett Smith wrote:
>
>> Can it be argued as to what "integer index" means? And what is a "string
>> index"?
>
> Good catch, that's pretty ambiguous language. Browsers implement this as
> if "integer index" were equal to the term "array index" defined section
> 15.4 of ECMA262 (that is an unsigned 32-bit integer other than
> (1<<32)-1, expressed in simplest-possible decimal form), and "string
> index" meaning any other index.
>

Not exactly.

An array's `length` is 1 greater than the largest index in the array;
represented as uint internally. The largest possible array index is
2^32 - 2. ES5 specification says this a bit differently:


| A property name P (in the form of a String value) is
| an array index if and only if ToString(ToUint32(P)) is
| equal to P and ToUint32(P) is not equal to 232-1

That could cover "integer index", but the remaining undefined is
"string index", which seems a paradoxical name, even for Java
programmers.

Suppose string index could be any other index. Or it could be any
index matching production for NAME.

But then, does that mean property access on an HTMLCollection can
never return undefined? Seems so; must be either `null` or an object.

If the a collection is spec'd to use specialized [[Get]] access, then
it may need to use catchalls. Again, browsers do use these in some
cases and they aren't specified.

> The paragraph should be updated to explicitly reference this; probably
> the language about square brackets should be dropped too, as it seems to
> represent a misunderstanding of exactly how the ECMAScript
> square-bracket and dot operators actually work.
>


> Whether a property name is an "array index" or not is an unrelated issue

Depends. If a specialized [[Get]] implemented as a catchall, then the
browsers do some checking.

A specialized [[Get]] may be interfering with array generics working
with IE host object collections. It may have been that it was too
complicated and that the developers decided that it was easier to fail
fast by throwing "JScript object expected'.

Again, on that error, if `ho` is a host object, then the behavior in
IE <= 8 for `[].slice.call( ho )` is "JScript object expected." IE
operation sees that the context -- the `this`value -- is not a JScript
object and then aborts prematurely, without trying. It could be that
the attempt to slice the object could actually succeed, as: -
  "0" in ho && "length" in ho

- is true.

> to the matter of how the property value is retrieved. OK, you can't use
> the direct dot syntax on an array index purely as a grammatical manner,
> but . and [] aren't the only way to access properties. (eg.
> document.links.hasOwnProperty('0').)
>

That shows that `hasOwnProperty` is present on the object and that
calling it returns true where there.

For compatibility with IE, a layer of indirection may be used:

({}).hasOwnProperty.call(document.links, "0");

- and resulting true in IE.

However, that hasOwnProperty check does not always true for
collections. As seen in the previous example I posted, for property P,
[[HasProperty]] resulted false when there is a property P. Once again,
this time with hasOwnProperty, I see a result in Firefox 3.6: [false,
object]

javascript: var result =
  [
  ({}).hasOwnProperty.call(document.forms[0], "0"),
  typeof document.forms[0][0]
  ];

 alert( result )

HTML5 also codifies a common form memory leak as "past names map".

Both of those oddities were explained more here:
<http://www.jibbering.com/faq/names/>

However, AFAIK, HTML5 does not specify the catchall behavior for the
approach for specialized property access seen there.

Does a collection have element properties?  (and by "element", I do
not mean Element, but indexed/keyed item that represents an object in
the collection.

If it does, then that's a lot easier. Spec'd specialized behavior for
property accessors can be removed; as that behavior is already defined
by ECMA-262. The only change could be to allow for "integer index"
access to return `undefined`, as it currently does in most browsers.

If any collection does not have element properties, then it is
necessary to define "integer index" and "string access", at least for
that collection.

Most collections appear to have element properties and so I can't see
any reason for not specifying that. I recall raising discussion of
property access on collections over a year ago, before writing the
article I've linked above.

Garrett