Property descriptor normalization (Was: General comments response (was Re: ES6 Rev13 Review: MOP-refactoring, symbols, proxies, Reflect module))

Allen Wirfs-Brock allen at
Sun Jan 6 14:28:45 PST 2013

On Jan 5, 2013, at 12:24 AM, Tom Van Cutsem wrote:

> 2013/1/4 Allen Wirfs-Brock <allen at>
> ...
> You're concerned about the nature of the descriptor object returned from the getOwnProertyDescriptor trap.  In particular, you want to have something stable enough that you can reason about it and reliably enforce whatever attribute invariants we may have.  
> I want to avoid cloning, extensive validation, or  normalization to data/accessor properties  of the object returned by the trap.
> As a middle ground that we can build upon I suggest we start with the following enforced invariants for the gOPD trap:
> 1)  The object returned must be an ordinary object
> 2)   If  the object has  value,get,set, writable, enumerable, or configurable properties, then those property must be  data properties.
> These rules indeed take away most of my fear of breaking existing code by guaranteeing the stability of "desc.configurable" etc.
> I wonder though how easy it is to verify part 2) since descriptor objects may inherit these properties. Since there is no [[GetProperty]] anymore, one would need to explicitly walk the proto-chain in search for the descriptor. This makes the verification more expensive again. It probably also means that property descriptors may not inherit from proxies.

If you think it is important, I'd be willing to go a step further and say that such properties must be own properties. It takes away some flexibility from handlers but I'm willing to give it up.  For reasoning purposes you probably you wouldn't want to allow exotic objects (including Proxies) on the prototype chain anyway.

Because Proxy [[GetOwnProperty]] normalized to a PD record it already has to look at these properties so verifying #2 for own properties would probably add very little extra cost.

> In addition,  handlers should adhere to the following unenforced rules:
> a) properties of the descriptor object should be configurable and writable (if a data property)
> b) a property descriptor should contain all information that would be necessary to create the property it describes, if that property did not already exist.
> c) If a property descriptor object contains either a "value" or "writable" property it should not also contain a "get" or "set" property.
> Failure to adhere to the unenforced rules may lead to unexpected client code behavior but does will not threaten the integrity or stability of the ES execution environment. 
> What do you think? Can we start with the above as a baseline?
> It's a start, but I'm still uncomfortable because of potential aliasing issues: if the returned descriptor object is not a copy, then a proxy handler may hold onto a reference to the returned descriptor object. This means it can still update the (mutable) descriptor after having returned it from the trap. The aliasing in combination with the mutability may still trip up clients unexpectedly.

Only if the client makes a call that gives control back to the handler (or its cohorts)  and, in general, all bets are off once you call into untrusted code.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the es-discuss mailing list