These are all good points. I'm not sure (1) is worth bringing back in all the "we won't let you say things you can't enforce" complexity, but (2) is maybe non-obvious enough not to be worth it. I'm backing off my "please make it null" position now. :) It actually seems pretty reasonable just to require an object, and this also leaves the door open to potentially expanding the API to allow primitive value proxies at some point down the road.
Dave On Oct 19, 2011, at 3:30 AM, Tom Van Cutsem wrote: > 2011/10/19 David Bruant <bruan...@gmail.com> > Le 19/10/2011 10:57, Andreas Rossberg a écrit : > If I understand the proposal correctly, you cannot avoid the > allocation, because the target is used as a backing store for fixed > properties. > Indeed. The target is "merged" with the "fixedProps" of the FixedHandler > proposal prototype implementation [1] > > That was in the old proposal. In the latest design [2], you don't necessarily > need to think of the target as a backing store, it's more as if the proxy > wants to keep the target "in sync" with the handler. > > If one would provide "null" as a target, then either: > (1) the proxy could throw when it would otherwise need to access the target > (e.g. to check for non-configurable properties). > (2) the proxy implicitly does create an empty target object, to be used as a > "backing store" for fixed properties, so to speak. > > I would much prefer (1): if you then want to create a fully virtual object > that only exposes configurable properties, there is no allocation overhead. > If you want (2), just call Proxy.for(Object.create(null), handler). > > This is a reason why a lot of checks that appear in Tom's Proxy.for are > actually not necessary (and won't be a performance burden) since they are > performed by some native code implementing internal methods (ES5.1 - 8.12 for > native objects, but also the custom [[DefineOwnProperty]] for arrays if the > target is one, etc.) > > Not sure what you mean by "not necessary": it's true that I expect most > checks to be fast since they are very similar to checks that need to be > performed by existing built-ins, but that's not the same as stating that the > checks are not necessary. > > Cheers, > Tom > > [2] > http://code.google.com/p/es-lab/source/browse/trunk/src/proxies/DirectProxies.js > _______________________________________________ > es-discuss mailing list > es-discuss@mozilla.org > https://mail.mozilla.org/listinfo/es-discuss
_______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
