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

Mark S. Miller erights at google.com
Wed Sep 25 12:56:57 PDT 2013


On Wed, Sep 25, 2013 at 8:59 AM, Allen Wirfs-Brock <allen at wirfs-brock.com>wrote:

>
> On Sep 25, 2013, at 3:01 AM, David Bruant wrote:
>
>  Le 25/09/2013 11:18, Tom Van Cutsem a écrit :
>
>  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.
>
> 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.
>
>
> More generally, such simple Proxy's such as the date one above break for
> any target object that have internal identify dependencies upon the target
> object.  This might be private state dependencies but they also could be
> external relationships such as registering the object in a Map.
>

Identity dependencies work fine across full identity preserving membranes.
They *cannot* work at all across proxying patterns short of membranes.
Representing private state in this identity dependent manner enables it to
work across membranes. No other solution to private state has survived the
joint requirements of: preserving privacy and transparency across
membranes. Thus, we have zero solutions to private state that meet both of
these requirements and also work across non-membrane proxying patterns. I
propose that we solve only solvable problems, and give up on private state
across across non-membrane proxying patterns.



>
>
> 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.
>
>
> How is this clear at the level of specify the behavior of MOP operations
> for Proxy instances?  What is it that distinguishes a function that has
> such dependencies from one that doesn't.
>
> Also, one of the early goals of Proxy was to support self hosting of
> built-ins. Saying that the Proxy MOP implementation has special knowledge
> of all built-in methods would not be supportive of that goal.   As it now
> stands a self-hosted implementation of, for example, Date is quite possible
> and it would fail for the above Proxy example in exactly the same way as a
> "native" implementation.
>
> The issue isn't  built-in vs. self-hosted.  It's passing identify
> dependencies through a Proxy.
>
> 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).
>
>
> I don't think there is one, based upon Direct Proxies.  That's why if we
> want to have Proxy as a primitive that supports creating membranes we need
> to stop thinking about it as a more universal primitive that also supports
> things like transparent forwarding and try to find ways to avoid leading
> future JS programmers into that same confusion.
>
> Allen
>
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>


-- 
    Cheers,
    --MarkM
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20130925/cca498f6/attachment-0001.html>


More information about the es-discuss mailing list