direct_proxies "problem"

Allen Wirfs-Brock allen at wirfs-brock.com
Sat Jan 12 09:45:01 PST 2013


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 <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" 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
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20130112/d6b55fc2/attachment.html>


More information about the es-discuss mailing list