Re: HTMLCollection item() vs. namedItem() with [] syntax (detailed review of the DOM)

> Simon Pieters:
> > Below is what IE7 seems to do, where "obj" is what you pass to the [[Get]]
> > method...
> >
> >   1. If obj is an array, let obj be the array's first item.
> >
> >   2. If obj is an integer, a float or Infinity, then pass that to .item()
> >      and abort these steps.
> >
> >   3. If obj is a string, check whether the string matches the regex
> >      /^(\d+)(\..*)?$/. If it does, pass $1 to .item() and abort these
> > steps.
> >
> >   4. Pass obj.toString() to .namedItem().

That doesn't seem entirely compatible with the ES3 spec from what I
can see. On the other hand, [[Get]] is not overridden in ES3 at all,
and the property accessor functionality does the stringification
semantics before any call on [[Get]].

~~~~
11.2.1 Property Accessors
/.../
The production MemberExpression : MemberExpression [ Expression ] is
evaluated as follows:
1. Evaluate MemberExpression.
2. Call GetValue(Result(1)).
3. Evaluate Expression.
4. Call GetValue(Result(3)).
5. Call ToObject(Result(2)).
6. Call ToString(Result(4)).
7. Return a value of type Reference whose base object is Result(5) and
whose property name is Result(6).
/.../
~~~~

The call on [[Get]] is part of the internal Reference type, and in
other words takes place after stringification:

~~~~
8.7.1 GetValue (V)
1. If Type(V) is not Reference, return V.
2. Call GetBase(V).
3. If Result(2) is null, throw a ReferenceError exception.
4. Call the [[Get]] method of Result(2), passing GetPropertyName(V)
for the property name.
5. Return Result(4).
~~~~


I don't know how in line with the LHS expressions and the Reference
type parts of the spec scripting engines actually are, but an engine
that follows the ES3 spec on this point must simply accept that
stringification happens first. There are no arrays, or numbers, or
booleans, or anything else than strings in property accessors -
property names go through ToString prior to being handed over to the
library code (such as an overridden [[Get]]) at all.

However, there's another point to make...

On 09/07/07, Cameron McCormack <cam@mcc.id.au> wrote:
> That's different from what I currently have in the Bindings spec, which
> is basically "do a ToUint32() on the property name, and if the result is
> a non-negative integer, use the index getter, otherwise use the name
> getter".

That's logical and sound. I'd formulate it something like this though:
If ToUint32(propname) equals ToNumber(propname) use the index getter,
otherwise use the name getter. But that's only personal preference, I
prefer specifically comparing to the results from the ToNumber
algorithm instead of "if the result is a non-negative integer" since
that explains exactly how it is determined. (Or a method which gives
identical results to doing that comparison, of course.)


On 09/07/07, Cameron McCormack <cam@mcc.id.au> wrote:
> Do you think IE7's rules should be used?

I'd like to do some tests on this, but don't have time writing them
atm. Is IE7 using the parseInt algorithm instead of the ToUint32
algorithm, or is that just what it looks like to me? I really wouldn't
like to see hexadecimal and octal conversions in [[Get]] for DOM
collections when it's nowhere else in ECMAScript property access. The
whole reason for [[Get]] overriding is to make it more ECMAScript
like, not less.
-- 
David "liorean" Andersson

Received on Monday, 9 July 2007 11:55:33 UTC