On Jan 12, 2013, at 9:36 AM, Andrea Giammarchi wrote: > All good except it's impossible/not meant to recognize Proxies in JS world?
Note that Tom said: "recognize their proxies" (emphasis added). If it needs to, a membrane or any other proxy issuing subsystem should be able to recognize its own proxies. It can, for example, tag them using a private symbol or keep them in a weak map. You don't want to recognize other subsystems proxies as proxies. They're just objects to you. Allemn > > > On Sat, Jan 12, 2013 at 7:46 AM, Tom Van Cutsem <[email protected]> wrote: > 2013/1/11 Nathan Wall <[email protected]> > 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" > discussion. > > 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 DOM. > > Cheers, > Tom > > _______________________________________________ > es-discuss mailing list > [email protected] > https://mail.mozilla.org/listinfo/es-discuss
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
