On Aug 6, 2008, at 12:27 AM, Cameron McCormack wrote:
Hi Garrett.
Garrett Smith:
In EcmaScript, the property access operators seem to look like a
"getter" to Cameron. What they really do is provide access to
properties added to the collection, or, in one case (on one
implementation), this seems implemented as a "getter". A "getter"
is a
method that gets the value of a property of that name.
I’m sorry I haven’t had a chance to reply yet, I’ve been quite busy
with
other things and haven’t had a chance to work on Web IDL for the last
few weeks. (Actually I had a half written reply to your earlier mail
drafted, but I hadn’t got to finishing it yet.)
Your tests do show that the HTML collections expose items through real
properties rather than “fake” ones returned through a custom [[Get]].
So yes that means that HTML 5 won’t be able to use [IndexGetter]
etc. to
accurately describe current browser behaviour. That doesn’t
necessarily
mean that [IndexGetter] etc. will have to be changed, just that for
the
purpose of documenting HTML collections they’re insufficient.
I think Garret has a valid point (despite his needlessly rude tone)
that the way we describe magical dynamic properties in a way that
makes clear they are also visible to the "in" operator and to
Object.prototype.hasOwnProperty. Are there any DOM bindings that have
index (or named) properties which are *not* visible in such a way? If
not, then the current [IndexGetter] definition is useless and we need
a better formalism.
I think that Web IDL can’t provide as much syntactic help for HTML
collections where the properties are real. So HTML will probably have
to include a sentence such as:
I also don't understand what is meant to by calling some properties
"real". I don't think this is a meaningful distinction. The core of
the point that Garret raised (as far as I can tell) is that the
properties are visible to has/in checks as well as gettable, and I
think this is true in all cases of DOM objects with dynamic index/
named properties.
In the ECMAScript language binding, for every node in the collection
there must exist a property on the collection object whose name is
the index of the node in the collection, and whose value is the node.
With some wording about whether these extra properties take precedence
over other properties on the object due to the interface, etc. Ian?
I think Web IDL should provide a formalism to cater to this, because
nearly all bindings with special dynamic properties work like this
afaik. But I think it would have to involve a pseudo-method for the
"hasOwnProperty" check (which "in" is based on).
Regards,
Maciej
