[Harmony Proxies] Proposal: Property fixing

Cameron McCormack cam at mcc.id.au
Thu Jun 16 19:24:33 PDT 2011


Cameron McCormack:
> > Web IDL requires various properties to be non-configurable, but the ones
> > we care about here are just the ones that need to exist on objects that
> > will have to be implemented using proxies, right?

Mark S. Miller:
> Yes. And of those, only the ones that need to have magical behavior that
> violates the invariants associated with non-configurability. IIUC, this
> exempts WebIDL constants, as they never violate those invariants, no matter
> how weird their host object. Is this right?

That’s right, they really are constant, and they live on objects with no
magical behaviour.

> > I believe that list is only:
> >
> >  1. the length own property on array host objects
> >  2. each array index own property on an array host object
> 
> By "array host objects", do you mean, for example, NodeList? Is there a
> general definition of "array host object"?

No, NodeList is a regular IDL interface which has getters/setters
defined on it.

Array host objects are ones that feel a bit like native Arrays but are
under host object control and which are represented by T[] types in IDL.
They’re actually pretty much like a shorthand for defining an interface
like NodeList, except that they also have the Array prototype object in
their prototype chain.

(When we met late last year there was a hope to remove them from the
spec due to them not being used anyway, but it turned out I was wrong,
and they were being used.)

The T[] types: http://dev.w3.org/2006/webapi/WebIDL/#idl-array

How values of these types are represented using array host objects in
ES: http://dev.w3.org/2006/webapi/WebIDL/#es-array

Maybe in the future when real subclassing of Array can be done, we can
change the T[] type to do that instead of having completely separate
objects.

> I expect that "length" on array host objects should be treated however we
> treat "length" on regular arrays. Does this seem reasonable?

Yes.

> Why do array index own properties of array host objects need to be
> non-configurable? What would be lost if these were non-configurable but
> array host objects could refuse to delete them?

Not much, except for author confusion if they see they are configurable
but the object refuses to let them be reconfigured.  The alternative,
having them be non-configurable, non-writable (for read only arrays)
data properties whose value changes also has an element of confusion
about them, though.  I think on balance that leaving them be
configurable and refusing to reconfigure them is the lesser of the two
confusions.

I agree with other parts of this thread about having length on Array
instances be a non-configurable accessor property – that’s much closer
to how I’d expect length properties to be defined if we were doing it
from scratch, less magical.  (So in fact we could do that for array host
objects; it’s just written the way it is at the moment to mirror the
native Array length property.)

> > In my upcoming change, [[GetOwnProperty]] will be specified to
> > return this property descriptor for property "0":
> >
> >  { [[Writable]]:false, [[Enumerable]]:true, [[Configurable]]:true,
> >    [[Value]]:theHTMLFormElement }
> >
> > but to refuse to allow the property to be reconfigured.
> 
> Great! So long as this property claims to be configurable, it raises
> none of these issues.

Excellent.

> > It would be nice if the z property could be allowed to be defined and
> > exposed as a non-configurable property, but this can’t be done without
> > the proxy proposal changes being discussed here.
> 
> I'm curious why you think this would be nice?

Because it’s what the author requested.  Presumably they have some
reason for wanting to define a non-configurable property.

This wouldn’t work for objects with named properties, though, since if z
is first exposed as a non-configurable property, and then an item is
added to the collection later with the name "z", it will appear to have
changed.

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


More information about the es-discuss mailing list