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

Tom Van Cutsem tomvc.be at gmail.com
Wed Sep 25 02:18:24 PDT 2013


2013/9/24 Allen Wirfs-Brock <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.

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20130925/6d5d1472/attachment.html>


More information about the es-discuss mailing list