Re: [WebIDL] Trying to understand IndexGetter/NameGetter

On 10/8/09 1:32 AM, Cameron McCormack wrote:
>> 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.

It's not clear to me why this last sentence is true.  The property 
already exists.  So it seems like the verbiage in 4.5.2 would simply not 
apply, since "# none of the objects in the host object’s prototype chain 
have a property named ToString(I)." is false.  If the prototype chain is 
meant to exclude the object itself, then consider me setting [5] on the 
prototype.

What in the current text says anything about me losing the original value?

What's particularly weird here, in fact, is the hysteresis: If I set a 
property on the prototype first and then it becomes supported on the 
object then the object doesn't get a new property per the spec text, and 
if the order is reversed it does.

> 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.

There's another fundamental problem: in your above proposed scenario if 
I then remove the 3 links the property has to be removed, right?  Which 
means my value I set on document.links[5] is now gone, as is the 
property...  But that involves all nodelists knowing what their length 
is at all times, and precludes optimizations that lazily compute the 
length (or heck, de-optimizations that recompute the length every time 
the list is asked).

> 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.

I think we should fix this.  The current setup really doesn't work very 
well...  Gecko's ES implementation certainly has a hook that can be used 
by host objects to affect 'in' and enumeration behavior, and is what we 
use for nodelists.

-Boris

Received on Thursday, 8 October 2009 15:53:39 UTC