brandon at brandonbenvie.com
Sat Jan 12 15:32:33 PST 2013
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 <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):
> 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
> "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?
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the es-discuss