On Mon, Dec 15, 2014 at 10:22 PM, Anne van Kesteren <[email protected]>
wrote:
>
> On Mon, Dec 15, 2014 at 3:15 PM, Dmitry Lomov <[email protected]>
> wrote:
> > - At this time we do not support subclassing built-ins and DOM objects
>
> If you don't ship this part, isn't there quite a big risk that we
> might find out too late that the subclassing design for built-ins
> might be incompatible with the web? (I'm assuming the design of
> subclassing for built-ins is somewhat tightly coupled with the design
> of subclassing in general.)
>
If we were happy with the design, we would have implemented it.
But we are not. To clarify, let me give you an example.
Consider ImageData. As you know, the way to construct ImageData (with a
constructor) is to pass (array, width, height) or (width, height) to the
constructor.
After construction, width, height and data of ImageData are read-only.
Let's look at subclassing ImageData. The instance of our subclass must be
an exotic browser object corresponding to ImageData.
ES6 specs gives us two options as to how we initialize ImageData instance
in a sub-class.
Option 1: pass arguments to the constructor:
class MyImageData extends ImageData {
constructor(....) {
foobar(this); // what is the value of `this` before call to super?
super(640, 320); // remember EGA? :)
}
}
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.
All methods on ImageData or accepting ImageData need to make sure that
ImageData they get is fully initialized, or throw (?) otherwise.
This is a lot of work to implement and obviously a (security) bug-farm -
for very little gain.
Option 2: pass arguments to [[CreateAction]] hook.
[[CreateAction]] hook is the hook that is invoked directly before
construction, and has access to constructor arguments.
class MyImageData extends ImageData {
constuctor(array, width, height, ...extra) {
foobar(this);
super(); // this is no-op
}
}
The constructor itself is a no-op, and all initialization is done by
[[CreateAction]] hook. No uninitialized ImageData exotic object is exposed,
but *our subclass constructor had to take exact same arguments as ImageData
constructor*. This is unacceptable.
As you see, both options are not happy. It is my understanding (I might be
incorrect) that IE implements Option 2 in preview release.
Therefore we opted for a conservative subset of semantics for now.
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.
