andrea.giammarchi at gmail.com
Sat Jan 12 09:36:05 PST 2013
All good except it's impossible/not meant to recognize Proxies in JS world?
On Sat, Jan 12, 2013 at 7:46 AM, Tom Van Cutsem <tomvc.be at gmail.com> wrote:
> 2013/1/11 Nathan Wall <nathan.wall at live.com>
>> I thought part of the goal in ES6 was striving to make the DOM emulable
>> (dare I say implementable?) in pure ES. If that's the case, the inability
>> of DOM objects to be proxied sounds like a big deal.
> I think we are missing an important point in this whole "Proxy the DOM"
> The way I have always thought of how "emulating the DOM using proxies"
> would work is as follows:
> 1) a DOM-in-JS library (like dom.js) exports an API that is an exact
> mirror copy of the DOM API.
> 2) some of these exported methods may create and return proxies that
> emulate particular DOM objects.
> 3) application code that uses this library only ever interacts with these
> emulated DOM objects *via the DOM emulation library's API*. In other words,
> it *never* would try to pass an emulated DOM node into the actual DOM.
> Doing that is just a plain type error.
> The cases where I think libraries like dom.js make sense is:
> - in an environment that doesn't have a real DOM at all (e.g. NodeJS)
> - in a sandboxed environment (like SES) where the sandboxed code cannot
> ever access the real DOM.
> In neither of these cases, the problem comes up.
> In general, when you're emulating a system, it is almost never the case
> that emulated objects must run on the *real* system directly. The real
> system doesn't know about the emulation's implementation layer, so it can't
> "interpret" the emulated object.
> Choosing to automatically unwrap the proxy and pass in the wrapped DOM
> node is dangerous. As Brendan mentioned, it breaks the proxy's abstraction.
> In that regard, I agree with Jason that it's best to think of a proxy's
> "target" as an encapsulated, internal piece of proxy state that should
> never leak. At best, external code can use the target to derive some simple
> information (like typeof does on direct proxies).
> The suggestion of allowing proxies to hook into the deeper DOM protocols
> and intercept inner calls (via symbols or however else you want to do that)
> seems to me a terrible idea.
> It seems at least some people here agree.
> To summarize, to me, emulating the DOM is as much about proxying DOM
> objects as it is about wrapping the actual DOM functions (like
> appendChild). It's the job of the wrapped functions to recognize their
> proxies, unwrap them, and pass their unwrapped counterpart into the real
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the es-discuss