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

David Bruant bruant.d at
Wed Sep 25 03:02:22 PDT 2013

Le 25/09/2013 12:01, David Bruant a écrit :
> Le 25/09/2013 11:18, Tom Van Cutsem a écrit :
>> 2013/9/24 Allen Wirfs-Brock <allen at 
>> <mailto: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.
> 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.
> 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).
Can relationships help here?

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

More information about the es-discuss mailing list