Le 25/09/2013 11:18, Tom Van Cutsem a écrit :
> 2013/9/24 Allen Wirfs-Brock <allen at wirfs-brock.com 
> <mailto:allen at wirfs-brock.com>>
>
>     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).

David
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20130925/e83ecd2b/attachment.html>

Le 25/09/2013 11:18, Tom Van Cutsem a écrit :

> 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).