On Tue, Dec 16, 2014 at 11:07 AM, Boris Zbarsky <[email protected]> wrote: > > On 12/16/14, 1:56 AM, Dmitry Lomov wrote: > >> the problem with this option is that between entry to the constructor >> and call to super(...) `this` is necessarily an exotic ImageData in some >> sort of semi-initialized state. >> That semi-initialized state has never been exposed to Javascript before, >> and our code is just not ready for this. >> > > This was also my take on the situation in Gecko+SpiderMonkey, until I > realized that we can simply allocate an object with the right memory layout > but not actually brand it as an ImageData object until the ImageData > constructor executes. > > The hard part, of course, is "brand it as an ImageData object" in a > dynamic way. That's not possible with the current SpiderMonkey API, but > internally SpiderMonkey already has facilities for doing things like that, > and we can add API for them. Such facilities may not exist in all ES > implementations, of course....
Correct. We do not have separate 'branding' and 'initialization' steps and we would hate to introduce it. > > > All methods on ImageData or accepting ImageData need to make sure that >> ImageData they get is fully initialized, or throw (?) otherwise. >> > > With the above approach this is not an issue, because such methods will > behave just like they would if the object involved were created via "new > Object". > > This is a lot of work to implement and obviously a (security) bug-farm - >> for very little gain. >> > > I agree that there's work involved here, but I disagree that this is a > security bug-farm if things are done in a principled way. > > More to the point, this has been hashed out ad nauseam in TC39 meetings > and on es-discuss. The two options you describe are the only ones that > people have managed to come up with that are at all sane. I disagree of course. The above two options are insane. > 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. -- -- 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.
