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

Tom Van Cutsem at
Sat Jan 5 00:24:24 PST 2013

2013/1/4 Allen Wirfs-Brock <allen at>

> On Jan 4, 2013, at 12:05 AM, Tom Van Cutsem wrote:
> From your point of view, it's only natural that proxies would be an ES6
> programmer's tool to define and experiment with entirely new types of
> properties.
> From my point of view, it's problematic (as in: not backwards-compatible)
> that ES6+ would expose any new type of property via existing APIs at all
> (with proxies or even just directly in the spec itself).
> We will need some agreement on this higher-level point before we can make
> good decisions at the level of the Proxy API.
> But are orthogonal issues that I think we an make some progress on.
> 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.

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

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

More information about the es-discuss mailing list