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 _______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
