Will any new features be tied to constructors?

Allen Wirfs-Brock allen at wirfs-brock.com
Wed Jul 1 14:48:38 UTC 2015


On Jun 30, 2015, at 5:57 PM, Domenic Denicola wrote:

> From: es-discuss [mailto:es-discuss-bounces at mozilla.org] 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





More information about the es-discuss mailing list