Re: indexed properties on NodeLists and HTMLCollections

Allen Wirfs-Brock:
> 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.

Hmm.  Not requiring specific [[Get]] and [[Put]] behaviour because they
are specification devices and not hooks for other specifications to use
as extension points is what I heard a while ago, and why I’ve been
trying to move away from using them.  But I suppose that this was
motivated by the fact that, without proxies, it wasn’t possible to
implement their non-native-object behaviour with native JS.

Presumably proxies will be specified part of the JS language in the
future, exposed like the rest of the built-in objects.  Why would they
be more of an implementation device then than custom [[Get]]/[[Put]]
definitions?  Wouldn’t it be safer for us to define behaviour in terms
of specific Proxy objects so that we can be sure that what we define is
implementable in pure JS?

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

OK.  This also seems counter to what I have been hearing – that we
should attempt to align with native JS object semantics unless
absolutely necessary.  I think in this case, the less native semantics
is easier for authors to understand (and has the desired performance
characteristics) so we should go with that if it is acceptable.

Disallowing the creation of non-configurable properties on NodeLists
that look like array index properties would help us avoid the problem
with Proxies not being able to expose a property as non-configurable at
one point and configurable the next.

> If user defined indexed properties are problematic can we ban them
> entirely?

I think that’s worth considering, too, especially if we are thinking of
the indexed properties as being a separate layer on top of the object –
intercepting [[DefineOwnProperty]] to prevent their creation in the
first place would simplify things.

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

OK.

About the requirement for Proxies to expose only configurable
properties: would that mean that a NodeList object, implemented as a
Proxy, can’t preserve the non-configurability of any properties on it?
For example:

  var list = document.documentElement.childNodes;
  // list is a NodeList that happens to be implemented by a Proxy
  Object.defineOwnProperty(list, "a", { configurable: false, value: 1 });
  alert(Object.getOwnPropertyDescriptor(list, "a").configurable);

would that alert true?  If so, is that seen as a problem?


I would like to hear from implementors whether they

  1. are happy treating indexed properties as a layer above the normal
     object property resolution (like Chrome/Safari do);
  2. think disallowing user defined non-configurable array index
     properties, or disallowing all user defined array index properties,
     as own properties on NodeLists/HTMLCollections is a good idea.

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

Received on Thursday, 5 May 2011 00:33:08 UTC