Catch-all proposal based on proxies

Brendan Eich brendan at
Wed Dec 9 11:02:36 PST 2009

On Dec 7, 2009, at 4:11 PM, Tom Van Cutsem wrote:

> Dear all,
> Over the past few weeks, MarkM and myself have been working on a  
> proposal for catch-alls for ES-Harmony based on proxies. I just  
> uploaded a strawman proposal to the wiki:

Hi Tom, great to see this proposal. I took the liberty of making a few  
small edits; hope they're ok. I like the stratification and the ab- 
initio nature of the design -- the last seems to me to be a crucial  
improvement over past proposals, which may help overcome the "climbing  
the meta ladder" objection.

Some initial comments, pruned to avoid restating others' comments:

1. This proposal obligates the catch-all implementor to delegate to  
any prototype object in has and get, to include unshadowed prototype  
properties in enumerate, to shadow if p in receiver.[[Prototype]] in  
put, and to do nothing for delete proxy.p if !proxy.hasOwnProperty(p).

In general, handler writers have to implement standard prototype-based  
delegation if it is desired. This is probably the right thing, but I  
wonder if you considered the alternative where prototype delegation is  
handled "by the spec" or "by the runtime" and the proxy is considered  

2. The fix handler returning undefined instead of throwing explicitly  
to reject a freeze, etc., attempt is a bit implicit. Falling off the  
end of the function due to a forgetten or bungled return will do this.  
Ok, let's say the programmer will test and fix the bug.

But more significant: could there be a useful default denoted by  
returning undefined or falling off the end of the fix function? An  
alternative interpretation would be an empty frozen object. This has  
symmetry with undefined passed (or no actual argument supplied) to  
Object.create. It's a minor comment for sure.

3. Mozilla's wrappers (proxies, membranes), which we pioneered for  
security purposes (e.g. for DOM inspectors where privileged JS is  
interacting with web content objects) and which have been copied in  
other browsers (at least WebKit), implement === by unwrapping, so two  
wrappers for the same object are === with that object, and with each  

The proxies proposal does not have an unwrapped object, although  
super? is similar. Later in the proposal, you write "meta-level code  
will ‘see’ the proxy rather than the object it represents." This  
sounds more like wrappers as we use them -- there is always a wrapped  
object and its proxy or wrapper.

The alternative of not trapping === is a leaky abstraction that  
inevitably breaks some programmers' expectations. Our early wrappers  
did not hook ===, but eventually we settled on the unwrap-before-===  
behavior based on testing.

This is a use-case I wanted to bring to your attention (Mike Samuel  
raised it in his reply by suggesting a Proxy.proxies predicate; his  
[[Class]] question also gets to the broader issue of transparency vs.  
leaky proxy abstractions). Our wrapper experience suggests allowing  
=== to be hooked in a constrained way, for certain kinds of proxies.  
It could be that this use-case can't be served by a standardized,  
general proxy/catch-all proposal, and must be done under the hood and  
outside of the ES spec.

4. The [[Get]] versus [[Invoke]] rationale: indeed performance is a  
concern, but existing engines also specialize callee-computation  
distinctly from get-value, in order to optimize away Reference types.  
The ES specs so far do not, instead using the internal Reference type  
to delay GetValue so as to bind |this| to the Reference base when  
computing a callee and its receiver as part of evaluating a call  

  I think it is an open question whether a future spec, especially one  
using a definitional interpreter, will stick to References. If we end  
up making the distinction that all practical implementations already  
make, between get-as-part-of-callee-computation and all other get- 
value "gets", then I don't think this rationale is so strong.

In general over-coupling to ES5 may not help either a new Harmony-era  
proposal to "get in", or to be as complete or expressive as it should  
be. So a rationale based on choices or limitations of ES1-5 seems weak  
to me.

Thanks again for this proposal,

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

More information about the es-discuss mailing list