[Harmony Proxies] Proposal: Property fixing

Mark S. Miller erights at google.com
Thu Jun 16 18:39:02 PDT 2011

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

> Hi Mark.
> Mark S. Miller:
> > Can we gather a list of all magical host properties that WebIDL says are
> > currently non-configurable but that proxies can't emulate unless they are
> > made configurable?
> 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?

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?

>  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"?

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

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?

> Constants map to non-configurable properties, but they exist only on
> interface objects and interface prototype objects, which are “normal”
> objects that wouldn’t need to be implemented using proxies.

Great! But as I mention above, I don't think these would be problematic in
any case.

> I will soon commit (probably today) a change to make indexed/named
> properties be exposed using custom [[GetOwnProperty]] and
> [[DefineOwnProperty]] handlers, which will mean objects that support
> indexed/named properties need to be proxies.  The relevant issue with
> these is that these objects must also expose non-configurable properties
> that users set on them.  For example:
>  <!DOCTYPE html>
>  <form name=a></form>
>  <script>
>    var forms = document.getElementsByTagName("form");
>    Object.defineOwnProperty(forms, "z", { value: 1 });
>  </script>
> forms needs to expose two properties, "0" and "a", whose values are the
> HTMLFormElement.  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.

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

>  But I don’t think it’s
> a huge loss if we just disallow non-configurable properties from being
> set on objects that support indexed/named properties.  My plan was to
> silently make [[DefineOwnProperty]] for such objects assume
> [[Configurable]] was true on the descriptor it receives.  Throwing would
> also be acceptable.

This is great! It looks like our hard issues are rapidly dissolving away.

> We could do the same thing for the array host objects mentio[ne]d at the
> top of the email, too: have the length and individual array index
> properties be reported as configurable, but to have
> [[DefineOwnProperty]] refuse to reconfigure them.

This is really awesome and much appreciated. Thanks for the clarifications!

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

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

More information about the es-discuss mailing list