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