On Tue, Dec 16, 2014 at 6:08 PM, <[email protected]> wrote: > > > > On Tuesday, December 16, 2014 2:50:40 AM UTC-8, Dmitry Lomov wrote: > ... >> >> >> >>> Is there a concrete plan for proposing something else, or is the >>> concrete plan to simply never allow subclassing of builtins? Because >>> that's the one concrete option 3 here, and it's not a very palatable or >>> desirable one either.... >> >> >> What we would propose is `this` being in TDZ until the call to >> 'super(...)'. Here is a brief summary: >> 1. [[CreateAction]] takes no arguments >> 2. Inherited [[CreateAction]] is only invoked if your subclass >> constructor calls 'super(...)', otherwise you get a plain Object. >> 3. If your subclass constructor calls 'super(...)', `this` is in TDZ >> until that super call. >> This has be be beaten on by the committee of course. >> > > Unless you intend to try to delay ES6 for at least 6 months there is no > time for the committee to beat on this. The final technical draft must be > be completed before the Jan. TC39 meeting in order to be on track for Ecma > approval in June. This week would be good time to resolve any remaining > issues. Why has this not been on es-discuss or the TC39 internal mailing > list? > > 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. >
How exactly do you mean? Do you mean my Option 1 or Option 2 (both are bad), or do you mean TDZ? > > Consider: No ES6 specified [[CreateAction]] has any dependencies upon the > constructor arguments and there is no current language level way to specify > the equivalent of a [[CreateAction]] for a class declaration. That means > that (for ES6) adding additional classes (for example DOM classes) that > provide a [[CreateAction]] is something that must happen in a > implementation specific manner using implementation specific interfaces. > Just as with "host objects" in previous ES editions, such implementation > level extensions are completely under your control. You can allow or forbid > [[CreateActions]] that use the constructor arguments, as you see fit. > So, consider again the example I above with ImageData. What do I do? No arguments to [[CreateAction]] is Option 1, problematic for reasons explained. Constructor arguments to [[CreateAction]] is Option 2, problematic for reasons explained. Therefore we have to punt on implementing this, hoping for a better resolution in ES7. Implementing ES6 builtin subclassing is just a lot of work, so we do not ship it yet. So what we ship today is a conservative subset of the full spec. 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.
