[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
Sun May 8 14:55:29 PDT 2011


Le 08/05/2011 22:58, Allen Wirfs-Brock a écrit :
> I also have similar concerns about the fix trap: "A non-extensible, sealed or frozen object should somehow restrict the handler’s freedom in terms of what it can return from subsequent calls to ‘set’, ‘get’ etc. For example, if previous invocations of handler.get(p, “foo”) returned a non-undefined value (for some ‘handler’ of a proxy p), then future invocations of handler.get(p, “foo”) should return the same value when p is frozen."  While I can almost rationalize why this might be ok for frozen objects I don't think it flies even there.  I certainly don't see why preventing the addition of new properties or making all properties non-configurable should disable all trapping behavior.  For example, I might want to use a Proxy to log trace accesses to specific properties.  Why should freezing the object block this.
We have discussed a similar point and one interesting solution came up
for the forwarding proxy case:
https://mail.mozilla.org/pipermail/es-discuss/2011-April/013573.html
It "saves" the behaviors for "get" and "set" traps (if these used to
call other traps, these traps will kept being called). It doesn't help
for other traps, though.


> (...)
> There are certain invariants that we expect the implementation of a ES object to maintain.  An implementation that doesn't is buggy.  Whether that implementation is expressed in terms of a Proxies, or a "host object" foreign function interface, or the implementation of the core built-in objects is irrelevant.  They all needs equal power or they aren't interchangeable as implementation alternatives.
I tend to agree... unless there would be security reason to state
otherwise. Proxies are user-inserted scripts and it may be a good enough
reason to diminish proxies power. I do not have an example in mind that
would justify this for now though.
Going in the direction you're describing would open the door for a
Object.getPrototypeOf trap (which I'm fine with).

David


More information about the es-discuss mailing list