direct_proxies "problem"

Jason Orendorff jason.orendorff at gmail.com
Wed Jan 9 08:27:38 PST 2013


On Tue, Jan 8, 2013 at 11:54 PM, Brendan Eich <brendan at mozilla.com> 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.

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.

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.)

-j
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20130109/b77d4409/attachment.html>


More information about the es-discuss mailing list