Re: [WebIDL] Trying to understand IndexGetter/NameGetter

[Adding public-script-coord and bccing public-webapps, since Web IDL
discussions are now meant to happen on the new list.]


Hi Boris.

Boris Zbarsky:
> In section 4.4.2 of WebIDL, there is the following language:
> 
>   As soon as a name N begins being able to be used to index
>   the host object, a property called the corresponding named
>   property  MUST be created on the host object...
> 
> IndexGetter has similar verbiage.  I'm really not clear on this
> "begins being able to be used" thing.  Is that something the
> interface needs to define?

Yes, though the latest draft of the spec has changed the wording a
little:

  http://dev.w3.org/2006/webapi/WebIDL/#indexed-and-named-properties

Basically, the prose in the spec defining the interface would define
what the set of “supported property indices” contains at any given time:

  http://dev.w3.org/2006/webapi/WebIDL/#dfn-supported-property-indices

When a new index becomes a part of that set, then a property is created
on the object.  When it is removed from the set, then the property is
deleted.

> In particular, consider using IndexGetter for NodeList.  At what
> point can "10000" be used to index the nodelist?  Is it as soon as
> the nodelist is created?  Once the length is > 10000?  Something
> else?

The spec for NodeList would state that the supported property indices
for the object would be all of the integers in the range
0 ≤ index ≤ length, where length is the number of items in the node
list.  With this definition, yes it would be once the length is > 10000.

> In particular, the interaction with existing properties interests
> me.

That indeed is the tricky bit. :-)

> If I set document.links[5] while the document has 3 links and then I
> add 3 more links, what is the value of document.links[5]?

Per the spec as currently written, assigning to document.links[5] would
create a property that is not one of the special ones automatically
created.  Then getting document.links[5] would get you the value you
just assigned to it.  If you then add three more links, then the value
of the document.links[5] property would be set to the appropriate
HTMLAnchorElement object, and you’d lose your original value.

However, and this doesn’t seem sensible, because the "5" property
already exists at the time the sixth link is added, it does have its
attributes set appropriately (e.g. ReadOnly if there is no index
setter), since they’re defined to be set only when such a property is
created automatically.  That seems like a bug with the current design.

> What if I had 6 links to start with?

Then assigning to document.links[5] would fail silently, as the property
would be ReadOnly (assuming NodeList not defined with an index setter).


Anyway, all of this seems a bit complicated and if we can get away with
a simpler model, such as how ES Array objects work, I’d rather that.

The only reason the current design is defined somewhat indirectly, and
defined as creating actual properties on the object (rather than
handling all of it within the [[Get]] and [[Put]]), is so that ‘in’ and
Object.hasOwnProperty() return true appropriately.  There’s no spec hook
in ES3 (or ES5 I think) to change how ‘in’ works on host objects.  All
that can be done is to make those properties actually exist.

-- 
Cameron McCormack ≝ http://mcc.id.au/

Received on Thursday, 8 October 2009 05:33:23 UTC