[Harmony Proxies] Proposal: Property fixing

Tom Van Cutsem tomvc.be at gmail.com
Fri Jun 17 07:51:44 PDT 2011

2011/6/17 David Bruant <david.bruant at labri.fr>

> Le 17/06/2011 08:31, Brendan Eich a écrit :
>> On Jun 16, 2011, at 10:12 PM, Mark S. Miller wrote:
>>> I agree. Sounds like a proxy. Glad we worked out the configurability
>>> issues.
>> Assuming Tom's fixed properties proposal (the latest) is approvied --
>> right?
> I think that there are still pending issues.
> One is figuring out why the ES5 invariants on abnormal+non-native object
> properties configurability are in the spec. If we assume they're legitimate,
> then we're pretty much done (not 100%, see below)
> As far as I'm concerned, I haven't read arguments enforcing a belief that
> these invariants on abnormal+non-native objects really have a value and why
> all implementations should follow them (Once again, they are in the spec, so
> they should be respected by implementors. But should they be in the spec?
> What is the added value of these 5 invariants? Why no other invariant?)
> For the moment, apparently, two cases are problematic:
> - A forwarding proxy cannot fully forward, because it cannot honestly tell
> whether a property in the target object is configurable or not (it will
> always pretend it's configurable). Since the forwarding proxy pattern is
> probably the most important, this seems to be a major issue.

I agree there doesn't seem to be a generic solution. However,
strawman:fixed_properties does make it possible for forwarding proxies to
deal with certain cases:
- if target has a non-configurable accessor property, the proxy can create a
fixed non-configurable accessor whose get/set attributes invoke
handler.get/set, as shown on the strawman page.
- if target has a non-writable, non-configurable data property (typically a
property just acting as a constant), the proxy can create its own fixed copy
of that property. IINM, non-writable non-configurable properties can't
change, so the copies cannot grow out of sync.
- if target has a writable, non-configurable data property, the proxy could
create a fixed copy. In its defineProperty trap, it has to make sure to
forward the defineProperty operation to the target, in case its writable
property is switched from true to false. The one thing the proxy cannot
intercept are changes made to the original property on its |target|. I.e.
the proxy may still advertise its fixed property as {writable:true,
configurable:false} while the target's property may have been changed to
{writable:false,configurable:false} by some other code.

Also, trying to create a non-configurable property on the target will not be
> possible (unless using custom property descriptor attribute? :-s), because
> with the fixed property proposal, such a property get stuck at the proxy
> level. No trap is called, no forwarding.

My latest addition to the proposal would allow proxy handlers to still
intercept defineProperty, even on fixed properties, so they could propagate
changes to fixed properties to their target.

> - Issue with a proxy saying that an inherited property is a
> non-configurable property (getPropertyDescriptor trap). Basically,
> getPropertyDescriptor may say that a property is configurable while
> getPrototypeOf+**getOwnPropertyDescriptor(on a native object which allows
> non-configurable property) may say that the property is not-configurable.
> They would both talk about the same property and be inconsistent.

Yes, this is a thorny issue. We could drop the getPropertyDescriptor
operation & trap. What we lose by that is that proxies would be unable to
fully emulate inherited properties. That is: while a proxy's get/set traps
may still emulate "foo" as an inherited property (i.e. proxy.foo returns a
value, but Object.getOwnPropertyDescriptor(proxy,'foo') returns undefined),
the illusion would be broken once the proxy's inheritance chain is inspected
(i.e. code may find out that there's actually no "foo" property on the
proxy's prototype chain). Actually, one could argue that even without
getPropertyDescriptor proxies already cannot emulate prototype inheritance,
since they can't virtualize Object.getPrototypeOf.


A branch of this thread took for granted the current spec invariants on
> abnormal+non-native object property configurability, but I'd like to
> question them and seen them justified before going further. The
> justification of these invariants (why each of them is here, in the spec?
> why no other invariant?) aren't currently obvious to me enough so that I'd
> defend them and enforce them on proxies.
> As far as I'm concerned, I care more about a fully honest forwarding proxy
> than any non-guarantee that "configurable:true" informs me of.
> Thanks,
> David
> ______________________________**_________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/**listinfo/es-discuss<https://mail.mozilla.org/listinfo/es-discuss>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20110617/86ac94d9/attachment.html>

More information about the es-discuss mailing list