[Harmony Proxies] On property descriptor auto-completion in defineProperty/get{Own}PropertyDescriptor traps (derived from: [Harmony Proxies] Proposal: Property fixing)

David Bruant david.bruant at labri.fr
Sat May 7 09:04:07 PDT 2011

Le 05/05/2011 20:38, Tom Van Cutsem a écrit :
> (...)
> Also, as you point out, full consistency across all traps is difficult
> to guarantee, so does it make sense to enforce consistency for some
> traps but not for others? The overall behavior of the proxy may still
> be inconsistent.
> I do see benefit in this proposal as an aid for proxy writers to
> develop more well-behaved proxies. But for that purpose it seems that
> this proposal can be fully written as a Javascript library layered on
> top of the existing API.
I think that these two points weigh in favor of not completing property
descriptor for the defineProperty/get{Own}PropertyDescriptor trap.
First, traps can ignore expected semantics of property attribute
("configurable", "enumerable" in particular), and by doing so, break
consistency with what we know of objects.
Then, completing property descriptors could be implemented as a library
on top of an existing non-completing proxy API. In order to help library
authors to implement such a thing, an
Object.prototype.toPropertyDescriptor method could be standardized
(following the definition at "ES5 8.10.5 ToPropertyDescriptor").

On the topic of defineProperty/get{Own}PropertyDescriptor traps, on the
open issue section of harmony:proxies is written: "Since a handler may
hold a reference to the property descriptor and change it later, should
the returned property descriptor object be copied?"
Last time I checked, FF4 implementation returns a copy (which is
consistent with ES5 ToPropertyDescriptor where a copy is performed to an
internal "Property Descriptor" representation). I think that this is a
good idea in order not the handler to be able to keep a reference to the
object. However, it has to be noted that it will prevent library writers
to use proxies as property descriptor (I am personally fine with this,
but it's worth noting).


More information about the es-discuss mailing list