[Harmony Proxies] Proposal: Property fixing
david.bruant at labri.fr
Fri Jun 17 05:59:18 PDT 2011
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
> Assuming Tom's fixed properties proposal (the latest) is approvied --
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
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.
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.
- 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
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.
More information about the es-discuss