Direct proxies strawman

William Edney bedney at technicalpursuit.com
Mon Oct 17 14:52:46 PDT 2011


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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20111017/3782be68/attachment-0001.html>


More information about the es-discuss mailing list