[Harmony Proxies] Proposal: Property fixing

Mark S. Miller erights at google.com
Thu Jun 16 19:44:19 PDT 2011

On Thu, Jun 16, 2011 at 7:24 PM, Cameron McCormack <cam at mcc.id.au> wrote:

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

Although <http://wiki.ecmascript.org/doku.php?id=strawman:proto_operator>
still appears in "strawman", I believe we accepted its functionality (with
concrete syntax still TBD) into ES-next "proposal" status, so it will become
standard at the same time proxies will. Of course, the current WebIDL JS
binding is targeting ES5 and so cannot directly rely on either proxies or
"<|". But perhaps we should choose an ES5 host behavior for array host
objects that anticipates reimplementing them using "<|" rather than proxies
in the ES-next timeframe? Perhaps we should choose an ES5 behavior that
leaves both future choices open? It sounds like we're already either there
or almost there.

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20110616/a9dff778/attachment.html>

More information about the es-discuss mailing list