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

Re: indexed properties on NodeLists and HTMLCollections

From: Cameron McCormack <cam@mcc.id.au>
Date: Thu, 23 Jun 2011 15:25:53 +1200
To: David Flanagan <dflanagan@mozilla.com>
Cc: Boris Zbarsky <bzbarsky@MIT.EDU>, Jonas Sicking <jonas@sicking.cc>, Allen Wirfs-Brock <allen@wirfs-brock.com>, public-script-coord@w3.org
Message-ID: <20110623032553.GC7924@wok.mcc.id.au>
David Flanagan:
> > > 1) A pre-existing named property will prevent the definition of
> > > an expando property with the same name, so there is no shadowing
> > > issue.
> 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().

You are right that the prevention of property assignment could be done
either in [[Put]] or in [[DefineOwnProperty]].  [[Put]] does call
[[DefineOwnProperty]] to do the actual property creation/modification,

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


Though I only made them configurable because with the proxy proposal you
wouldn’t be able to expose a non-configurable property.  I think there
was talk of allowing certain properties to be exposed as
non-configurable, but that still wouldn’t work here since these
properties still need to be able to change.

Allen mentioned that it is fine to refuse to reconfigure a property even
if it is configurable, and I just thought I would go the simpler route
and disallow it.

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

Actually I intended to disallow it, even with Object.defineOwnProperty,
when writing the text.  I don’t think it particularly matters whether we
allow this or not, though.  Are there any disadvantages either way?

> 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]]?

Oh yes, you are right.  [[Put]] will call [[CanPut]], which will return
false for the non-writable property descriptor returned from Web IDL’s
[[GetOwnProperty]].  (I’ll make your suggested change now.)

Cameron McCormack ≝ http://mcc.id.au/
Received on Thursday, 23 June 2011 03:26:34 UTC

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