On Tue, Dec 16, 2014 at 7:04 PM, Allen Wirfs-Brock <[email protected]> wrote: > > > On Dec 16, 2014, at 9:19 AM, Domenic Denicola wrote: > > > From: [email protected] [mailto:[email protected]] On Behalf > Of [email protected] > > > >> Let me turn this around on you. What in the current draft prevents you > from implementing object allocation lazily exactly as you describe above? > And is there anything in the current draft that would be incompatible with > future spec. changes such as formalizing the above or even going with the > full new^ proposal? I don't think so, but if you see something let me know. > > > > I think the TDZ semantics proposed are incompatible with the current > spec. That is, if V8 implemented the current spec, authors will start > writing code like > > > > ```js > > class Foo {} > > > > class Bar extends Foo { > > constructor() { > > this.baz = "qux"; > > super(); > > } > > } > > ``` > > > > But once this code is in the wild, introducing the TDZ Dmitry proposes > will break that code. So, if the current spec is implemented and shipped, > the TDZ can never be implemented. > > > > (The other direction, of course, is fine: if we have a TDZ in ES6, but > come up with a mechanism to loosen it later, that will *not* break any > non-pathological code.) > > I'd assumed that the TDZ extends to the this reference and at that point > the lazy allocation occurs. > > But why is this example even relevant. There are no [[CreateAction]]s > involved here. Why would you want to prevent somebody from writing such > code? The semantics of it is perfectly clear. And there is also no ES6 > built-in constructor that has a [[CreateAction]] where this won't do > exactly what is expected. > > The V8 concern seems to be about hypothetical that aren't actually in the > Es6 specification. Anything other than the [[CreateAction]]'s defined in > the ES6 spec. are non-standard implementation specific extensions. What an > implementation allows or doesn't allow for such extensions (if it allows > them at all) is completely up to it. But, making the above illegal would > clearly be a significant unilateral deviation from the specification, the > benefit of which I still don't see. >
Our concern here is not hypothetical, as my example with ImageData clearly illustrates - just replace Foo with ImageData in Dominic's example (or derive Foo from ImageData). These extensions might be non-standard from ES point-of-view, but DOM classes are very-very much standard in our browsers, and we just do not have either a standard for how to subclass these things, or a very good guidance for what those subclasses will be ([[CreateAction]] is problematic for the reasons above). Therefore we opt for a conservative thing. We extend this conservative point of view on normal ES classes as well out of abundance of caution. As the first implementors, we need to tread water carefully here. Dmitry -- -- v8-users mailing list [email protected] http://groups.google.com/group/v8-users --- You received this message because you are subscribed to the Google Groups "v8-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
