direct_proxies "problem"

Andrea Giammarchi andrea.giammarchi at
Sat Jan 12 15:37:05 PST 2013

double negation ... that cannot be solved in the ECMAScript domain ....

On Sat, Jan 12, 2013 at 3:36 PM, Andrea Giammarchi <
andrea.giammarchi at> wrote:

> my concern is about security problems too but at least having this spec'ed
> somewhere as known gotcha that cannot be solved not in the ECMAScript
> domain would be better than nothing.
> br
> On Sat, Jan 12, 2013 at 3:30 PM, David Bruant <bruant.d at> wrote:
>> Le 13/01/2013 00:18, Brandon Benvie a écrit :
>>  This isn't exactly a direct parallel because all the types that are
>>> included as part of ES6 will be proxyable in such a way that the proxy can
>>> be transparently interchanged with its target. The problem with DOM objects
>>> is that this isn't true. I think it would be a good practice for the
>>> providers of unproxyable platform APIs to be up front about their inability
>>> to be proxied successfully.
>> Andrea and I disagree on what "unproxyable" and "be up front about their
>> inability to be proxied successfully" mean. I'll try to summarize my and
>> Andrea's position the best I can (please Andrea, correct me if I'm mistaken
>> about your position):
>> "unproxyable"
>> Me: proxyability is about the Reflect API, so every object is proxyable
>> (but other types like numbers, booleans, etc. aren't)
>> Andrea: if a proxy to a DOM node cannot be substituted to a genuine DOM
>> node, then DOM nodes are unproxyable (can be applied to any sor of objects
>> obviously)
>> "be up front about their inability to be proxied successfully"
>> Me: it's enough if the specs are upfront (corollary: web specs need to
>> start talking about how they deal with proxies)
>> Andrea: the runtime needs to be upfront
>> Anyone wants to provide different definitions?
>> David
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the es-discuss mailing list