On Jun 30, 2015, at 5:57 PM, Domenic Denicola wrote: > From: es-discuss [mailto:[email protected]] On Behalf Of C. > Scott Ananian > >> But the design might work well as a proxy object? It could delegate to the >> "real" object, with its private slots, after that object is created. > > We briefly discussed this with the V8 team. Their opinion was that making > fast proxies was a problem at least as hard as making proto-swizzling work > seamlessly. Not to mention all the additional complexities introduced by > private state and proxies, which there are a few centithreads in the archives > about.
This could not be a normal proxy because the target object needs to be available when the proxy object needs to be created. Given that, I suspect that a special proxy could be introduced that dealt with those issues. But. I'm not necessarily advocating that solution. Do one has yet explained to me, what is wrong with simply initially inserting a dummy (generic) custom element node during DOM parsing and latter (after the required JS code has loaded) replacing that node with a new more specific node that is an instance of the named subclass. My premise is that once script is running DOM nodes can be arbitrarily added/removed/modified as a side-effect of any script function. Hence there is no guarantees that any two script navigations to some particular node location in the DOM will yield the same (===) object and scripts generally should not be making any such identity assumptions. If there are no identify assumptions, then you can safely replace such dummy custom element nodes with the actual node when it becomes available. (probably between microtasks, would be best) Allen _______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
