2013/9/24 Allen Wirfs-Brock <[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.
To me, this solution is appealing because it feels analogous to how we
solved the "subclassing built-ins" problem.
IIRC, the initial class proposal didn't cater to subclassing built-ins,
i.e. instances of class MyDate extends Date {...} would fail to be
recognized by built-in Date methods.
Allen then changed the way instance initialization works, allowing the
@@create method to "brand" the subclass instance as being of the right
"type" / having the right internal state.
Translating this solution to the proxying built-ins problem somehow
requires "branding" the proxy that it is of the right primitive type. The
easiest way to brand a proxy is simply to check whether its target is of
the right type. IOW, a proxy is-a built-in <=> its target is-a built-in.
This solution requires all built-in methods to try and unwrap proxies
passed as the |this| value. This would be just another branch in the
preamble of such built-ins. The actual built-in body will only operate on
the unwrapped value, which is always a genuine built-in value, with
whatever custom data layout the built-in expects.
The auto-unwrapping doesn't break membranes, because membranes never expose
direct references to built-in functions (they only expose wrapper
functions, which can still do whatever interposition they want before
calling the actual built-in).
Cheers,
Tom
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
