[Harmony Proxies] Proposal: Property fixing

David Bruant 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 
>> 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.
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 
inconsistent.

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


More information about the es-discuss mailing list