- From: Ryosuke Niwa <rniwa@apple.com>
- Date: Fri, 10 Jan 2014 16:01:37 -0800
- To: Boris Zbarsky <bzbarsky@MIT.EDU>
- Cc: Erik Arvidsson <arv@google.com>, Dominic Cooney <dominicc@google.com>, WebApps WG <public-webapps@w3.org>, Jonas Sicking <jonas@sicking.cc>, Edward O'Connor <eoconnor@apple.com>, William Chen <wchen@mozilla.com>
On Jan 10, 2014, at 8:16 AM, Boris Zbarsky <bzbarsky@MIT.EDU> wrote: > On 1/10/14 11:10 AM, Erik Arvidsson wrote: >> My hope was that it would be rare to override Symbol.create for Elements >> so in most cases we would not need to call user code. > > For spec purposes and parser implementation design purposes that doesn't matter. If user code can be called, the algorithms involved have to handle user code being called at that point and potentially tearing the world down (or apart, or just rearranging it in macabre ways like user code tends to do)... > >> After further discussing this with Dominic and others I've given up the >> hope that an object instance cannot be reached before the constructor >> has been called. This can happen due to navigating the DOM tree but also >> be manually calling `MyCustomElement[Symbol.create]()`. At this point I >> believe we should just resolve to best practice and that is to not use >> @@create directly and do not navigate the DOM tree in your constructors. > > Yeah, agreed. An alternative idea we had was to “recursively” call constructors on the “unconstructed” elements in such situations. So if the constructor of an element A tries to access to another unconstrcuted element B, then call B’s constructor at that point. Either solution is better than not being able to use ES6 classes in my opinion. - R. Niwa
Received on Saturday, 11 January 2014 00:01:52 UTC