A DOM use case that can't be emulated with direct proxies

Kevin Reid kpreid at google.com
Thu Dec 13 11:59:24 PST 2012


On Thu, Dec 13, 2012 at 11:47 AM, Jason Orendorff <jason.orendorff at gmail.com
> wrote:

> This target, even if dummy, is the one that will be used for invariants
>> checks. You can't get away from this by design. This is one of the most
>> important part of the direct proxies design.
>> Even if you switch of fake target, the engine will still perform checks
>> on the dummy internal [[Target]].
>>
>> I feel we're cycling in what we say and I feel I can't find the right
>> words to explain my point. One idea would be for you to implement a
>> target-switching proxy based on direct proxies (Firefox has them natively
>> or you can use Tom's shim [1]). I'm confident you'll understand my point
>> through this exercise.
>>
>
> David: https://gist.github.com/4279162
>
> I think this is what Kevin has in mind. Note in particular that the target
> of the Proxy is just a dummy object, and the handler ignores it entirely.
> The proxy uses it for invariant checks, but the intent is that those would
> always pass.
>

Yes, exactly. I was just this minute in the process of writing such a proxy
myself, and have not yet confirmed whether it is accepted by the invariant
checks for all the cases I'm thinking of (testing against FF 18.0).

Note that either
(1) all the switched-among targets need to have the same [[Prototype]],
(2) the proxy has to pretend that all inherited properties are actually own,
(3) or mutating [[Prototype]] (i.e. __proto__) needs to be possible.
In my particular use case, (1) is not a suitable option, so I would
implement (2) if (3) is not available. Not that I approve of (3), but one
does what one must to accomplish virtualization.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20121213/9827a9d4/attachment-0001.html>


More information about the es-discuss mailing list