On Tue, Dec 16, 2014 at 9:02 PM, Allen Wirfs-Brock <[email protected]> wrote: > > > On Dec 16, 2014, at 11:25 AM, Dmitry Lomov wrote: > > > > On Tue, Dec 16, 2014 at 7:04 PM, Allen Wirfs-Brock <[email protected]> > wrote: >> >> >> >> 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 > > > But there is noting called ImageData in the ES6 specification nor any > requirement that, if you implement this DOM class, that it be usefully > subclassable, You may implement it using any sort of exotic object > restrictions including providing a [[Construct]] semantics that does > anything you want. The ES level definition of things like ImageData and > the ability to subclass them is certainly a concern for post-ES6 editions > of the standard but is not something that can be addressed right now. >
Yes, that is why we are conservative in our implementation. But I'd like to stress that subclassable DOM objects are definitely a goal of this feature and having a path forward here is urgently needed. I think I explained quite adequately the problems that arise with trying to extend current ES6 spec hooks (including [[CreateAction]]) for DOM objects. > > You are certainly free to stage you implementation of ES6 in whatever > order words best for you and ultimately confirming to ES6 or not is a your > choice. Your ImageData concerns are not a problem for any of the ES6 > specified built-ins and certainly not an issue for ES level class > definitions that don't subclass such built-ins. > True for plain ES6 classes. Less true for bulitins implementation-wise (fair amount of work and possible bug farm, for quite diminishing returns; likely loss of some optimizations for small typed arrays) - frankly I expect this to be a long tail of work. > Other implementation have alway weighed in and said that they can live > with what is current in the ES6 spec. I hope that your conservatism isn't > really a form of obstructionism. > The only implementation that ships (experimentally) is IE, and my understanding (again please correct me if I am misrepresenting) is that DOM objects subclassing there works by providing arguments to [[CreateAction]] (Option 2 if you still follow my example). We believe this to very much be not the right thing, so yes we would definitely not support this design choice. Call this obstructionism if you like :) 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.
