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

Mark S. Miller erights at
Wed Sep 25 06:49:54 PDT 2013

Why does Date need private state? AFAICT, it only needs uniquely named
state. Why not do what we've done for many other bits of internal state
that doesn't need to be private: just name it with a unique symbol? This
doesn't work for all internal state of course, but it does seem it would
work for Date.

On Wed, Sep 25, 2013 at 3:02 AM, David Bruant <bruant.d at> wrote:

>  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>
>> 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?
> David
> _______________________________________________
> es-discuss mailing list
> es-discuss at

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

More information about the es-discuss mailing list