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

Allen Wirfs-Brock allen at wirfs-brock.com
Fri Jan 4 09:33:08 PST 2013


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.

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?

Allen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20130104/6a79cced/attachment-0001.html>


More information about the es-discuss mailing list