direct_proxies "problem"

David Bruant bruant.d at
Thu Jan 10 00:35:08 PST 2013

Le 09/01/2013 23:57, Andrea Giammarchi a écrit :
> do you have any example of what you are saying? all my examples fail 
> and I don't understand other use cases.
I don't. You seem to be relying a lot on the Firefox implementation, but 
there are 2 things to be aware of as far as I know (sorry I didn't bring 
that up earlier):
1) its use with non-ECMAScript standard objects hasn't been thought out 
too much, so shouldn't be taken as authoritative
2) the implementation is not complete [1]. The "depends on" list of the 
bug contains bug regarding missing traps, misbehaviors regarding 
invariants and a couple of other things.

Given 1), all what I've been talking about is a discussion on how 
proxies should behave and more importantly, what different specs should 
be saying about this. I haven't even tried anything I suggested because 
I was aware the current Firefox implementation cannot be considered up 
to spec.

Before we start any conversation on whether Firefox is making a good 
decision of shipping proxies in the arguably incomplete state that they 
are, I'd like to remind this warning that can be read on the MDN page 
almost since day 1 of the doc page [2]:
"Warning: The SpiderMonkey Proxy implementation is a prototype and the 
Proxy API and semantics specifications are unstable. The SpiderMonkey 
implementation may not reflect the latest specification draft. It is 
subject to change anytime. It is provided as an experimental feature. Do 
not rely on it for production code."

I've just added a note in the Firefox 18 for developers page in that 
direction too.

> As you said, if a Proxy should be undetectable
I wrote "undetectable from the objects they try to emulate *from the 
ECMAScript perspective* (internal 
Whether an non-standard API decides to accept proxies in its internal 
methods is a different story.

> a broken Proxy that cannot be used is a pointless object full of 
> inconsistency in the environment, IMHO.
> Is this the decision then? Let the new Proxy accept any target even if 
> the target cannot be "proxied" ?
I guess it all depends on what one means by "cannot be used" and "cannot 
be proxied". If what you expect is things like 
wrappedNode1.appendChild(wrappedNode2) to work if the wrapped nodes are 
part of the same membrane, that could be made functional (unwrap under 
the hood, perform the native action and return wrapped objects when 
applicable). If you want to use the Reflect API on them (what I call 
"from the ECMAScript perspective"), that could work too. And I think 
that makes a self-consistent useful set of things.
If you want something that can be appended to the DOM (or used with the 
tree manipulation methods), we've clarified that it's not possible. But 
I don't think it's a good enough reason to prevent proxying altogether.

Now, one major point you're revealing is the lack of specification. 
Maybe either WebIDL or all spec writers should be made aware of this 
issue so that they start thinking of whether the algorithms applied on 
the objects they define would work as well on proxied versions of their 
objects. Depending on the answer choosing to throw when this |this| or 
an argument is a proxied version of the object they're defining.

If specs explain this choice, you may still be frustrated, but at least 
reading the spec will cut the surprise.



More information about the es-discuss mailing list