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 <[email protected]
<mailto:[email protected]>>
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
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
