Intent to ship: ES6 classes.

[Dmitry Lomov]

[blink-dev: FYI]

Classes syntax are part of ES6. The spec in Editor's draft is stable.

IE has classes in preview release [1]. No other browser currently ships classes (Mozilla bug [2]).

V8 implementation of classes is up-to-date with the latest ES6 spec modulo the limitations noted below.

Limitations:

- Classes are dependent on lexical declarations. Since the latter are currently only supported in strict mode, we currently only support classes in strict mode as well.

- At this time we do not support subclassing built-ins and DOM objects

- Current ES6 specification (in particular, [[CreateAction]] hook that takes arguments) makes design of subclassable exotic (in particular DOM) objects unclear. We intend to work with involved parties on resolving this difficulty, but for now we add an extra limitation to calls to super constructor in subclasses: if a subclass constructor calls a superclass constructor via ‘super(...)’ call, that call must be the first statement of constructor’s body, and arguments to ‘super(...)’ call can not refer to ‘this’. 

We intend to lift this restriction in the future, once we clarify the design for exotic objects’ subclassing.

Owners: a...@chromium.org, dsl...@chromium.org

[1] https://status.modern.ie/classeses6

[2] https://bugzilla.mozilla.org/show_bug.cgi?id=837314

[Elliott Sprehn]

On Mon, Dec 15, 2014 at 6:15 AM, Dmitry Lomov <dsl...@chromium.org> wrote:

[blink-dev: FYI]

Classes syntax are part of ES6. The spec in Editor's draft is stable.

IE has classes in preview release [1]. No other browser currently ships classes (Mozilla bug [2]).

V8 implementation of classes is up-to-date with the latest ES6 spec modulo the limitations noted below.

Limitations:

- Classes are dependent on lexical declarations. Since the latter are currently only supported in strict mode, we currently only support classes in strict mode as well.

- At this time we do not support subclassing built-ins and DOM objects

- Current ES6 specification (in particular, [[CreateAction]] hook that takes arguments) makes design of subclassable exotic (in particular DOM) objects unclear. We intend to work with involved parties on resolving this difficulty, but for now we add an extra limitation to calls to super constructor in subclasses: if a subclass constructor calls a superclass constructor via ‘super(...)’ call, that call must be the first statement of constructor’s body, and arguments to ‘super(...)’ call can not refer to ‘this’. 

We intend to lift this restriction in the future, once we clarify the design for exotic objects’ subclassing.

Is the super() restriction true for all subclassing, or just exotic subclassing?

[Dmitry Lomov]

On Mon, Dec 15, 2014 at 7:35 PM, Elliott Sprehn <esp...@chromium.org> wrote:

On Mon, Dec 15, 2014 at 6:15 AM, Dmitry Lomov <dsl...@chromium.org> wrote:

[blink-dev: FYI]

Classes syntax are part of ES6. The spec in Editor's draft is stable.

IE has classes in preview release [1]. No other browser currently ships classes (Mozilla bug [2]).

V8 implementation of classes is up-to-date with the latest ES6 spec modulo the limitations noted below.

Limitations:

- Classes are dependent on lexical declarations. Since the latter are currently only supported in strict mode, we currently only support classes in strict mode as well.

- At this time we do not support subclassing built-ins and DOM objects

- Current ES6 specification (in particular, [[CreateAction]] hook that takes arguments) makes design of subclassable exotic (in particular DOM) objects unclear. We intend to work with involved parties on resolving this difficulty, but for now we add an extra limitation to calls to super constructor in subclasses: if a subclass constructor calls a superclass constructor via ‘super(...)’ call, that call must be the first statement of constructor’s body, and arguments to ‘super(...)’ call can not refer to ‘this’. 

We intend to lift this restriction in the future, once we clarify the design for exotic objects’ subclassing.

Is the super() restriction true for all subclassing, or just exotic subclassing?

All subclassing (for now). 

[Anne van Kesteren]

On Mon, Dec 15, 2014 at 3:15 PM, Dmitry Lomov <dsl...@chromium.org> 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.)


--
https://annevankesteren.nl/

[Dmitry Lomov]

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

[Boris Zbarsky]

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

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

-Boris

[Dmitry Lomov]

On Tue, Dec 16, 2014 at 11:07 AM, Boris Zbarsky <bzba...@mit.edu> 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.

[al...@wirfs-brock.com]

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.

 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. 

You know that I'm aligned with you on how this should work in the long term.  That long term solution can't get into ES6. The only issue for now, is whether there is anything about the current specification that we can't subsume into a better design that includes language level support.

[Domenic Denicola]

From: blin...@chromium.org [mailto:blin...@chromium.org] On Behalf Of al...@wirfs-brock.com

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

I think the TDZ semantics proposed are incompatible with the current spec. That is, if V8 implemented the current spec, authors will start writing code like

```js
class Foo {}

class Bar extends Foo {
constructor() {
this.baz = "qux";
super();
}
}
```

But once this code is in the wild, introducing the TDZ Dmitry proposes will break that code. So, if the current spec is implemented and shipped, the TDZ can never be implemented.

(The other direction, of course, is fine: if we have a TDZ in ES6, but come up with a mechanism to loosen it later, that will *not* break any non-pathological code.)

[Allen Wirfs-Brock]

I'd assumed that the TDZ extends to the this reference and at that point the lazy allocation occurs.

But why is this example even relevant. There are no [[CreateAction]]s involved here. Why would you want to prevent somebody from writing such code? The semantics of it is perfectly clear. And there is also no ES6 built-in constructor that has a [[CreateAction]] where this won't do exactly what is expected.

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.

Allen

[Dmitry Lomov]

On Tue, Dec 16, 2014 at 6:08 PM, <al...@wirfs-brock.com> 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

[Dmitry Lomov]

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

[Allen Wirfs-Brock]

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

[Dmitry Lomov]

On Tue, Dec 16, 2014 at 9:02 PM, Allen Wirfs-Brock <al...@wirfs-brock.com> wrote:

On Dec 16, 2014, at 11:25 AM, Dmitry Lomov wrote:

On Tue, Dec 16, 2014 at 7:04 PM, Allen Wirfs-Brock <al...@wirfs-brock.com> 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

[Anne van Kesteren]

On Tue, Dec 16, 2014 at 9:43 PM, Dmitry Lomov <dsl...@chromium.org> wrote:
> 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.

Agreed, Mozilla would also really like to see this solved. It's
somewhat annoying to learn that TC39 is apparently no longer
delivering on explaining DOM in terms of ES6.

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

This was actually part of my concern. If you don't ship this
refactoring, we won't know whether this refactoring of builtins is web
compatible. And if we later find out it's not and requires changes to
the way subclassing is done in general, what can we do?


--
https://annevankesteren.nl/

[Dmitry Lomov]

Before we ship anything we need to implement it, so I am sorry Anne that me and other engineers working on this feature fell short of your high expectations here :)

Seriously though, making bulitins subclassable is quite a lot of work in the engine (I have to point out again that in particular [[CreateAction]] and exposure of un-(or, rather semi-)initialized bulitins makes implementation much more complex that it might have been). 

As in any project, we have to prioritize what features we are working on when, and as in any project we have a limited number of available qualified hackers.

What would you prefer, arrow functions or an ability to subclass Date?

Dmitry

[Boris Zbarsky]

On 12/16/14, 1:56 AM, Dmitry Lomov wrote:

> Option 2: pass arguments to [[CreateAction]] hook.
> [[CreateAction]] hook is the hook that is invoked directly before
> construction, and has access to constructor arguments.

Dmitry,

I finally have all this stuff paged in again. Sending one last mail
here to make sure we're on the same page, and my apologies for hijacking
your lists.

So if I recall correctly, the setup with [[CreateAction]] is meant to
allow subclassing of builtins without requiring implementations to
expose uninitialized builtin objects, with the restriction you mention:
the constructor arguments have to have the builtin constructor arguments
as a prefix.

I _believe_ the idea is that this allows some subclassing of builtins
and that once we (TC39 + WebIDL) have sorted out how to do whatever it
is we're doing in ES7 we can loosen the argument order restriction
without breaking anything that's already using the current setup.

I know you think the argument order restriction is unacceptable, but
it's not being proposed to stay long-term.

I agree with you that even subject to this restriction we may want a TDZ
to avoid pages coming to rely on calling the super-constructor (which
happens to be a no-op in the [[CreateAction]] case) after messing with
"this" and thus precluding migration to whatever it is ES7 ends up doing.

It is, of course, up to you to choose what you implement, but I wanted
to make sure we were all clear on the fact that option 2 doesn't require
that arguments match up in perpetuity; it merely allows subclassing
builtins earlier than we could otherwise, subject to this restriction on
the subclass.

-Boris

[Dmitry Lomov]

On Tue, Dec 16, 2014 at 11:19 PM, Boris Zbarsky <bzba...@mit.edu> wrote:

On 12/16/14, 1:56 AM, Dmitry Lomov wrote:

Option 2: pass arguments to [[CreateAction]] hook.
[[CreateAction]] hook is the hook that is invoked directly before
construction, and has access to constructor arguments.

Dmitry,

I finally have all this stuff paged in again.  Sending one last mail here to make sure we're on the same page, and my apologies for hijacking your lists.

So if I recall correctly, the setup with [[CreateAction]] is meant to allow subclassing of builtins without requiring implementations to expose uninitialized builtin objects, with the restriction you mention: the constructor arguments have to have the builtin constructor arguments as a prefix.

I _believe_ the idea is that this allows some subclassing of builtins and that once we (TC39 + WebIDL) have sorted out how to do whatever it is we're doing in ES7 we can loosen the argument order restriction without breaking anything that's already using the current setup. 

I know you think the argument order restriction is unacceptable, but it's not being proposed to stay long-term.

Nothing is more permanent than temporary measures, as the saying goes.

[[CreateAction]] with arguments is clearly a wrong design, and until we see a clear path for removing the argument order restriction, it is irresponsible to ship a broken thing with no recourse.

Dmitry

[al...@wirfs-brock.com]

On Wednesday, December 17, 2014 12:41:56 AM UTC-8, Dmitry Lomov wrote:

On Tue, Dec 16, 2014 at 11:19 PM, Boris Zbarsky <bzba...@mit.edu> wrote:

On 12/16/14, 1:56 AM, Dmitry Lomov wrote:

...

I _believe_ the idea is that this allows some subclassing of builtins and that once we (TC39 + WebIDL) have sorted out how to do whatever it is we're doing in ES7 we can loosen the argument order restriction without breaking anything that's already using the current setup. 

I know you think the argument order restriction is unacceptable, but it's not being proposed to stay long-term.

Nothing is more permanent than temporary measures, as the saying goes.

[[CreateAction]] with arguments is clearly a wrong design, and until we see a clear path for removing the argument order restriction, it is irresponsible to ship a broken thing with no recourse.

 We really need to take this discussion to a different venue.  But to wrap things up here:

The specific built-ins defined in ES6 are intended to be subclassable. That's the high order bit. The exact mechanisms used to specified that is less important and need not be applyied to future built-ins or implementation provided built-ins such as the DOM.  [[CreateActiuonb]] was never intended as anything  more than a temporary fix that TC39 agreed to at our November meeting so ES6 could move forward to completion.

The specification of the ES6 built-in does not depend upon the passing of constructor arguments to [[CreateAction]].  Hence, it is irreverent from the perspective of of the requierment that ES6 built-ins are subclassable.

From that perspective I have no problem with a change to the ES6 draft spec. such that ordinary [[Construct]] (as applied to the ES6 built-ins) does not pass any arguments to the [[CreateAction]].

Would that change make any difference to you position.

Allen

 

[Elliott Sprehn]

What does the spec define is the state of objects before super() is called?

new (class extends Date {

  constructor(value) {

    console.log(this.getTime());

    super(value);

  }

})

What does that print? Is the spec explicit about how all built in types behave before super() is called?

- E

[Boris Zbarsky]

On 12/17/14, 5:04 PM, Elliott Sprehn wrote:
> What does the spec define is the state of objects before super() is called?

It depends on the object.

> new (class extends Date {
> constructor(value) {
> console.log(this.getTime());
> super(value);
> }
> })
>
> What does that print?

Per spec, the [[CreateAction]] of Date creates an object whose
[[DateValue]] internal slot is set to undefined. See
http://people.mozilla.org/~jorendorff/es6-draft.html#sec-properties-of-the-date-constructor

Then the getTime method is specified in
http://people.mozilla.org/~jorendorff/es6-draft.html#sec-date.prototype.gettime
to "Return this time value" which links to
http://people.mozilla.org/~jorendorff/es6-draft.html#sec-properties-of-the-date-prototype-object
which will throw a TypeError when [[DateValue]] is undefined.

So the above code will throw a TypeError.

> Is the spec explicit about how all built in types
> behave before super() is called?

Yes.

-Boris

[Dmitry Lomov]

On Tue, Dec 16, 2014 at 10:56 AM, Dmitry Lomov <dsl...@chromium.org> wrote:

 It is my understanding (I might be incorrect) that IE implements Option 2 in preview release.

I stand corrected - Brian Terlson (cc'd) informed me that IE does not currently implement subclassing exotic objects (ES6 or DOM).

Thanks Brian!

[Ojan Vafai]

On Tue Dec 16 2014 at 2:19:30 PM Boris Zbarsky <bzba...@mit.edu> wrote:

I finally have all this stuff paged in again.  Sending one last mail
here to make sure we're on the same page, and my apologies for hijacking
your lists.

For the record, we love it when other browser vendors chime in on blink-dev intent threads. It's not at all hijacking. The primary point of intent threads is to work towards an interoperable, open web. Part of that is welcoming involvement from other browser vendors and, of course, web developers. We won't always agree in the end, but the discussion is valuable regardless.