[Harmony Proxies] Proposal: Property fixing

Mark S. Miller erights at google.com
Thu Jun 16 20:13:42 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
Why does each array host object have its own toString method rather than
using one inherited from Array.prototype? ES5 already says that
Array.prototype.toString is "intentionally generic; it does not require that
its *this* value be an Array object." So that should work fine.

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

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

More information about the es-discuss mailing list