David - You did give an answer on that bug, and I do appreciate it :-). I wanted to raise the issue here for folks that are not subscribed to that bug, since it seems (thankfully) that the proposed functionality hasn't been frozen yet.
I guess what would be missing for me is that, unless I misunderstand your proposed syntax there, the creation of the 'Array' using the '<|' operator would still require the creator to use said syntax. What I'm looking for is "transparent" behavior (i.e. if I'm using a third-party library that uses '[]' to create Arrays, for instance, it 'automagically' gets my Proxy/backstop behavior). 'Proxy.startTrapping()' sounds very interesting... a quick search didn't turn up anything. Do you have any pointers to discussions, strawmen, etc.? Cheers, - Bill On Oct 17, 2011, at 4:43 PM, David Bruant wrote: > Le 17/10/2011 21:43, William Edney a écrit : >> >> Tom - >> >> Been following the proxy work for quite a while and, as the original >> requestor for __noSuchMethod__ to be added to Spidermonkey, I have been keen >> to see the functionality as I describe here: >> >> https://bugzilla.mozilla.org/show_bug.cgi?id=683218#c8 >> >> I'm not sure as to whether direct proxies would solve that problem for me. >> AFAICT, they wouldn't... > Direct proxies can be used to implement the previous proposal and the > previous proposal can be used to implement direct proxies, so direct proxies > cannot solve more than the previous proxy proposal could. > > I gave an answer to your concern. See > https://bugzilla.mozilla.org/show_bug.cgi?id=683218#c13 > > Direct proxies have access to the target (which is mostly the equivalent to > accessing the proxy in the previous design). Combined with the proto > operator, it seems that you could mostly solve your use case. > What would be missing? > > Additionally, Proxy.startTrapping could be helpful to you (though it may be > too controversial. We'll see) > > David > >> >> Comments? >> >> Cheers, >> >> - Bill >> >> On Oct 17, 2011, at 2:15 PM, Tom Van Cutsem wrote: >> >>> Hi, >>> >>> A couple of weeks ago, Mark and I sat together to work on a number of open >>> issues with proxies, in particular, how to make proxies work better with >>> non-configurable properties and non-extensible objects. The result is what >>> we call "direct proxies": in our new proposal, a proxy is always a wrapper >>> for another "target" object. By slightly shifting our perspective on >>> proxies in this way, many of the earlier open issues go away, and the >>> overhead of proxies may be substantially reduced in some cases. >>> >>> I just finished a first draft of the strawman: >>> <http://wiki.ecmascript.org/doku.php?id=strawman:direct_proxies>. Feedback >>> welcome. >>> >>> A prototype implementation that builds upon FF7 proxies is available also: >>> <http://code.google.com/p/es-lab/source/browse/trunk/src/proxies/DirectProxies.js> >>> (note: I still need to thoroughly test this code, but it's otherwise an >>> accurate description of the semantics of direct proxies in terms of current >>> proxies.) >>> >>> Mark and I will present this proposal in detail at the TC39 November >>> meeting. In the meantime, it may use some es-discuss eyeballs. >>> >>> To whet your appetite, some advantages of direct proxies w.r.t. the current >>> proposal: >>> - Enable emulation of non-configurable properties. >>> - Enable emulation of non-extensible, sealed and frozen objects. >>> - Proxies inherit [[Class]] from target. Enables faithful wrapping of Host >>> objects, Arrays, etc. >>> - “Fixing” a proxy (i.e. stopping the handler from trapping), is decoupled >>> from “protecting” a proxy (making it non-extensible, sealed or frozen). >>> - No need to distinguish between object and function proxies anymore. >>> - All traps become optional. >>> - Wrapping an existing object using a direct proxy creates less overhead, >>> no need to pass through an explicit ForwardingHandler anymore. >>> - Proxies can't violate non-configurability / non-extensibility invariants. >>> This in turn enables safe transformation of regular objects into proxies >>> (Proxy.attach) >>> - The default forwarding handler becomes a stateless singleton object. >>> >>> Also, thanks to David Bruant for being an early sounding board and >>> providing some useful API tweaks. >>> >>> Cheers, >>> Tom >>> _______________________________________________ >>> 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 >
_______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
