Jason Orendorff wrote:
On Tue, Jan 8, 2013 at 11:54 PM, Brendan Eich <[email protected]
<mailto:[email protected]>> wrote:
Boris and I talked more 1:1 -- it is not clear when a direct proxy
can be safely "cast" to its target. The internal proxies Gecko
uses are known implementations where this is safe (with a security
check). An arbitrary scripted direct proxy? Not safe in general,
and stripping the proxy to its target may break the abstraction of
that certain scripted proxy.
Hard-earned wisdom:
1. Proxies that form membranes always have wrap/unwrap operations that
can be sensibly applied in every situation—except access to an
object's implementation details, like internal properties; then it’s
unclear.
2. Proxies that exist only to give a particular object magical
behavior should never be "cast to its target".
What 1 and 2 have in common is that only the handler ever sees both
the proxy and the target. The main lesson I've drawn from Mozilla's
experience with proxies is that this property is crucial.
I buy this analysis.
Still doesn't mean direct proxies are a net loss from the original
target-free API. Direct proxies solved the non-configurable issue and
simplified by eliminating function proxies as distinct at create-time.
And one can use direct proxies as if they were indirect, with a dummy
target and some work.
My old bones are aching in ways that make me think we could use two
kinds of APIs. Notification proxies were suggested last fall. We have
limited time for ES6 to call this, though.
Without it, you get a mess that's impossible to reason about. The
symptoms are a proliferation of special cases where something must be
wrapped or unwrapped with a lengthy comment explaining why; code where
a particular variable could be either a target or a proxy; and related
bugs due to the code naively assuming one or the other.
Beyond the wrap/unwrap special casing, it sounds like proxied
abstractions are leaking. Is this accurate and useful? Abstractions
leak, utopia not an option....
The default direct proxy you get with an empty handler does *not* have
this property; my hard-earned lesson predicts that we would therefore
have a lot of trouble figuring out exactly what that could usefully
do, and in fact we have had trouble. (It's not the only source of
trouble; access to object implementation details are trouble too.)
(Implementation details => abstraction leaks for sure, no?)
/be
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
