I agree with that. This isn't something that belongs in ECMAScript, it's out of scope. As you said, this is a conversation that needs to be had in the space of DOM specifications/implementations.
On Sat, Jan 12, 2013 at 6: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
