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

Re: indexed properties on NodeLists and HTMLCollections

From: Allen Wirfs-Brock <allen@wirfs-brock.com>
Date: Tue, 3 May 2011 08:13:32 -0700
Cc: public-script-coord@w3.org, bzbarsky@mit.edu
Message-Id: <37696418-7B3D-478D-8BB0-115180041AA2@wirfs-brock.com>
To: Cameron McCormack <cam@mcc.id.au>

On May 2, 2011, at 10:24 PM, Cameron McCormack wrote:
> ...
> This behaviour is, IIRC, what Web IDL used to require a while ago, when
> it had explicit [[Get]] and [[Put]] definitions for host objects
> implementing interfaces.
> In the future, once Proxies are in a spec and everyone’s implementing
> them, I think we should speccing indexed property behaviour Web IDL
> directly in terms of them.  We’re not at that point yet, though.  In the
> meantime, we need to specify something that will be compatible with
> going in that direction.

I don't think you should plan on using Proxies to specify these semantics.  Proxies are an implementation device that ,among other things, permit the native JavaScript implementation of objects that have non-normal [[Get]] and [[Put]] semantics. Essentially, they were created to enable JavaScript implementations of things like NodeList.

WebIDL should use explicit [[Get]] and [[Put]] definition to specify these semantics.  

In doing so, you should try to select a semantics that makes sense  for a usage perspective.  It also doesn't have to match the normal [[Get]]/[[Put]] semantics nor does it have to conform to the normal [[DefineOwnProperty]] semantics (eg, it might disallow allow the creation of non-configurable array indexed properties).  If user defined indexed properties are problematic can we ban them entirely?

> What is currently specified is not implemented completely by anyone, and
> looks to have poor performance characteristics, but at least doesn’t
> fall afoul of host object rules and could be implemented in a native SS
> DOM.  What Chrome/Safari do, to me, seems more understandable for
> authors, but breaks ES semantics a little.

The normal ES semantics rules are expected to be broken in this situation.  The specification and implementation mechanism I mention above all exist to deal with such breakage.  We should be looking for a semantics that makes sense in the context of the normal usage cases of these particular objects.

> What should we do?
> -- 
> Cameron McCormack ≝ http://mcc.id.au/

Received on Tuesday, 3 May 2011 15:14:08 UTC

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