Proxying built-ins (Was: [[Invoke]] and implicit method calls)

Allen Wirfs-Brock allen at
Wed Sep 25 08:59:30 PDT 2013

On Sep 25, 2013, at 3:01 AM, David Bruant wrote:

> Le 25/09/2013 11:18, Tom Van Cutsem a écrit :
>> 2013/9/24 Allen Wirfs-Brock <allen at>
>> I think this is a key point.  Things like 'new Proxy(new Date, {}).getDate()' just don't work as expected with direct proxies and we have not been able to fix that while maintaining other important semantic requirements.   If JS programmer have an expectation that they can usefully write such code they are going to be disappointed.  Direct proxies seem to be a fine primitive for implementing membranes and some virtual objects.  They aren't good for things like this Date example.
>> In my original direct proxies proposal, this would have worked because I proposed that a Proxy-for-a-Date be recognized as a genuine Date, with all Date.prototype.* methods auto-unwrapping the proxy, operating on the actual Date target.
>> Off the top of my head I don't recall why this was a no-go.
> IIRC, the problem was that this solution wasn't generic enough because it couldn't work with userland private state. Auto-unwrapping with Date and Set works because interaction is always through methods. It is less clear how it should work for userland private state.

More generally, such simple Proxy's such as the date one above break for any target object that have internal identify dependencies upon the target object.  This might be private state dependencies but they also could be external relationships such as registering the object in a Map. 

> Builtins are easy, because it's very clear which method is expected to work with which object; there is a clear definition of what an "instance" is and that can be tracked internally. Also, the auto-unwrapping can be done safely, because it's done internally. None of these two are true for userland private state.

How is this clear at the level of specify the behavior of MOP operations for Proxy instances?  What is it that distinguishes a function that has such dependencies from one that doesn't. 

Also, one of the early goals of Proxy was to support self hosting of built-ins. Saying that the Proxy MOP implementation has special knowledge of all built-in methods would not be supportive of that goal.   As it now stands a self-hosted implementation of, for example, Date is quite possible and it would fail for the above Proxy example in exactly the same way as a "native" implementation.

The issue isn't  built-in vs. self-hosted.  It's passing identify dependencies through a Proxy. 

> I think it's important to have a generic solution to avoid having magic (non-self-hostable) built-ins (but I don't have this solution).

I don't think there is one, based upon Direct Proxies.  That's why if we want to have Proxy as a primitive that supports creating membranes we need to stop thinking about it as a more universal primitive that also supports things like transparent forwarding and try to find ways to avoid leading future JS programmers into that same confusion.

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

More information about the es-discuss mailing list