A DOM use case that can't be emulated with direct proxies
bruant.d at gmail.com
Wed Dec 12 12:35:59 PST 2012
Le 12/12/2012 21:09, Kevin Reid a écrit :
> On Wed, Dec 12, 2012 at 12:03 PM, David Bruant <bruant.d at gmail.com
> <mailto:bruant.d at gmail.com>> wrote:
> Le 12/12/2012 20:49, Kevin Reid a écrit :
>> I haven't made it public yet, but it's just the obvious
>> implementation of an (old-style, as implemented in
>> Firefox/Chrome) proxy with a switchable “target”.
> Interesting. As I said, target-switching won't be possible in
> direct proxies.
> I understand that direct proxies have an internal “target” object.
> Will it not be possible to simply never place any properties on said
> object (thus not constrain future behavior) while still appearing to
> have properties? This text suggests that is a possible and expected
> Since this Proxy API requires one to pass an existing object as a
> |target| to wrap, it may seem that this API precludes the creation
> of fully “virtual” objects that are not represented by an existing
> JSObject. It’s easy to create such “virtual” proxies: just pass a
> fresh empty object as the target to |Proxy| and implement all the
> handler traps so that none of them defaults to forwarding, or
> otherwise touches the|target|.
> In my case there is an actual object, of course, but I implement
> forwarding to said object myself; the JS implementation never knows
> that I am “treating it as a target”.
I was a bit too strong in my statement, sorry. Let me rephrase: the
internal [[Target]] can't be changed, but a proxy can emulate changing
of "fake" target as long as what happens with this "fake" target doesn't
involve invariant checking.
That's the reason I was suggesting that WindowProxies could (maybe
depending on how the object reference was obtained) throw whenever
invariant checks are involved.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the es-discuss