Direct proxies strawman

David Bruant bruant.d at
Mon Oct 17 14:43:16 PDT 2011

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:
> 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

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)


> 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: <>.
>> Feedback welcome.
>> A prototype implementation that builds upon FF7 proxies is available
>> also: <>
>> (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 <mailto:es-discuss at>
> _______________________________________________
> es-discuss mailing list
> es-discuss at

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the es-discuss mailing list