direct_proxies "problem"

Andrea Giammarchi andrea.giammarchi at gmail.com
Sat Jan 12 15:36:21 PST 2013


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 gmail.com> 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: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20130112/b0bd9274/attachment.html>


More information about the es-discuss mailing list