double negation ... that cannot be solved in the ECMAScript domain .... yeah!
On Sat, Jan 12, 2013 at 3:36 PM, Andrea Giammarchi < [email protected]> 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 <[email protected]> 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 >> > >
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
