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. 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. 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. Allen -- -- 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.
