W3C home > Mailing lists > Public > public-script-coord@w3.org > April to June 2011

Re: indexed properties on NodeLists and HTMLCollections

From: David Flanagan <dflanagan@mozilla.com>
Date: Wed, 22 Jun 2011 10:04:37 -0700
Message-ID: <4E0220A5.1040001@mozilla.com>
To: Boris Zbarsky <bzbarsky@MIT.EDU>, Jonas Sicking <jonas@sicking.cc>, Allen Wirfs-Brock <allen@wirfs-brock.com>, public-script-coord@w3.org
On 6/21/11 9:17 PM, Cameron McCormack wrote:
> David Flanagan:
>> I suspect that is what the ES-262 says to do even without proxies,
>> so my new interpretation of how named properties and expandos should
>> interact is the following:
>> 1) A pre-existing named property will prevent the definition of an
>> expando property with the same name, so there is no shadowing issue.
>> 2) A pre-existing expando will shadow a named property that comes
>> into existance after the expando. [This is different than the
>> current behavior of FF and Chrome, at least.]
>> Is this the intent of the spec?
> Yes, that is the intent.  I think then that Web IDL’s
> [[DefineOwnProperty]] needs to change to ensure (1).  (2) should already
> work.
I'm thinking about point 1 again after a good night's sleep... My phrase 
"prevent the definition of" conflates two things: ordinary property 
assignment which rejects attempts to set own properties without ever 
calling [[DefineOwnProperty]] and explicit calls to Object.defineProperty().

Named properties look like configurable read-only own properties.  If 
these were on an ordinary JavaScript object, then attempting to set them 
with ordinary assignment would fail, but setting them with an explicit 
call to Object.defineProperty() would succeed.  That, I think, is the 
behavior that the spec already has in its current state, and maybe that 
is just what we want: you can't override a named property accidentally, 
but you can if you really want to.

On the other hand, I suppose that is what [[ReplaceableNamedProperties]] 
is for.  Named properties on interfaces with ReplaceableNamedProperties 
are supposed to be replaceable through regular assignment and not just 
through Object.defineProperty(), right?  I don't think that works 
currently.   Maybe in [[GetOwnProperty]] step 2.7, make the property 
writeable if there is a setter or if [[ReplaceableNamedProperties]]?

Received on Wednesday, 22 June 2011 17:05:15 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:03 UTC