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
[[Get]]/[[DefineOwnProperty]]/[[Keys]]...)."
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.
David
[1] https://bugzilla.mozilla.org/show_bug.cgi?id=703537
[2]
https://developer.mozilla.org/en-US/docs/JavaScript/Reference/Global_Objects/Proxy
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
