Editorial: Remove 'designed to be subclassable' #2360

ptomato · 2021-03-25T20:55:46Z

As discussed during the March 2021 plenary, this note on "is designed to
be subclassable" can be read as an encouragement or value judgement on
whether it is desirable to subclass built-in classes like Boolean. We
don't want to actively encourage this.

ptomato · 2021-03-25T20:56:48Z

Hi, I thought it'd be good to start a discussion around the removal of this phrase (which was mentioned in plenary) in order to provide a basis for the language in Temporal to be consistent with. Please do suggest alternatives 😄

ljharb · 2021-03-25T21:10:47Z

spec.html

@@ -24492,7 +24492,7 @@ <h1>The Object Constructor</h1>
        <li>is the initial value of the *"Object"* property of the global object.</li>
        <li>creates a new ordinary object when called as a constructor.</li>
        <li>performs a type conversion when called as a function rather than as a constructor.</li>
-        <li>is designed to be subclassable. It may be used as the value of an `extends` clause of a class definition.</li>
+        <li>may be used as the value of an `extends` clause of a class definition.</li>


this is definitely better! but:

Suggested change

<li>may be used as the value of an `extends` clause of a class definition.</li>

<li>may be used as the value of an `extends` clause of a class definition, but is not intended to be subclassed.</li>

perhaps? (at least for all the non-nullish primitive constructors, where it just doesn't make sense to ever subclass them)

ljharb · 2021-03-25T21:12:23Z

spec.html

@@ -27366,7 +27366,7 @@ <h1>The Date Constructor</h1>
        <li>creates and initializes a new Date object when called as a constructor.</li>
        <li>returns a String representing the current time (UTC) when called as a function rather than as a constructor.</li>
        <li>is a function whose behaviour differs based upon the number and types of its arguments.</li>
-        <li>is designed to be subclassable. It may be used as the value of an `extends` clause of a class definition. Subclass constructors that intend to inherit the specified Date behaviour must include a `super` call to the Date constructor to create and initialize the subclass instance with a [[DateValue]] internal slot.</li>
+        <li>may be used as the value of an `extends` clause of a class definition. Subclass constructors that intend to inherit the specified Date behaviour must include a `super` call to the Date constructor to create and initialize the subclass instance with a [[DateValue]] internal slot.</li>


Date seems like it works fine as being subclassable

Similar response here as above for Error.

ljharb · 2021-03-25T21:12:43Z

spec.html

@@ -30767,7 +30767,7 @@ <h1>The RegExp Constructor</h1>
        <li>is <dfn>%RegExp%</dfn>.</li>
        <li>is the initial value of the *"RegExp"* property of the global object.</li>
        <li>creates and initializes a new RegExp object when called as a function rather than as a constructor. Thus the function call `RegExp(&hellip;)` is equivalent to the object creation expression `new RegExp(&hellip;)` with the same arguments.</li>
-        <li>is designed to be subclassable. It may be used as the value of an `extends` clause of a class definition. Subclass constructors that intend to inherit the specified RegExp behaviour must include a `super` call to the RegExp constructor to create and initialize subclass instances with the necessary internal slots.</li>
+        <li>may be used as the value of an `extends` clause of a class definition. Subclass constructors that intend to inherit the specified RegExp behaviour must include a `super` call to the RegExp constructor to create and initialize subclass instances with the necessary internal slots.</li>


sadly, RegExp was explicitly designed to be subclassable

I'm still curious. Does anyone use subclassable RegExp in wild? I never seen that

Neither have i, but the committee decided not to remove that plumbing, and it was definitely designed for it.

sadly, RegExp was explicitly designed to be subclassable

Doesn't mean we need to mention that in the specification, though.

I think it’s reasonable to denote the things that are built for it, to separate them from the ones that aren’t.

If “properly work” means “RegExp subclasses don’t work, which is fine because nobody actually uses them except for core-js feature detection”, then they’d just use those methods directly. If by “properly work” you mean that RegExp subclasses continue to work, then no, of course those are required.

@ljharb by "properly" work I mean how to make work extended transpiled functionality of RegExp - NCG in this case - work with String.prototype.match and String.prototype.replace. It's absolutely not related to polyfills - it's the implementation of ES2018 feature on ES2015. You say that "they could drastically simplify their output" - I have no ideas how it could be implemented without ES2015 subclassing with delegation to .exec and @@replace how it's implemented at this moment or without patching built-ins (unacceptable on the transpilers side).

For that, you’re probably right - but “making transpilers possible” isn’t a primary concern when designing features.

However, it's a significant plus.

When possible, yes, but it's not worth the complexity and performance hits that the RegExp system takes. Unfortunately, we can't remove it because there's no practical way to tease apart polyfill feature detections from real code when gathering usage data.

Jack-Works · 2021-03-26T03:15:07Z

spec.html

@@ -25626,7 +25626,7 @@ <h1>The Error Constructor</h1>
        <li>is <dfn>%Error%</dfn>.</li>
        <li>is the initial value of the *"Error"* property of the global object.</li>
        <li>creates and initializes a new Error object when called as a function rather than as a constructor. Thus the function call `Error(&hellip;)` is equivalent to the object creation expression `new Error(&hellip;)` with the same arguments.</li>
-        <li>is designed to be subclassable. It may be used as the value of an `extends` clause of a class definition. Subclass constructors that intend to inherit the specified Error behaviour must include a `super` call to the Error constructor to create and initialize subclass instances with an [[ErrorData]] internal slot.</li>
+        <li>may be used as the value of an `extends` clause of a class definition. Subclass constructors that intend to inherit the specified Error behaviour must include a `super` call to the Error constructor to create and initialize subclass instances with an [[ErrorData]] internal slot.</li>


Actually, I do see and use subclassing on the Error constructor. Isn't it is designed subclassable?

Error doesn't have any methods outside of toString, which side steps the issues with subclassing. Still I don't see any reason to deviate from the proposed language here. I see this PR as removing encouragement, and IMO, the fact that Error can be successfully subclassed doesn't mean the spec needs to encourage it over other built-ins that can't be easily successfully subclassed.

Further, by removing the encouragement, we're also saying something about future proposals for extending Error: that they shouldn't accommodate subclassing beyond the constructor being usable in extends.

Jack-Works · 2021-03-26T03:16:19Z

spec.html

@@ -31492,7 +31492,7 @@ <h1>The Array Constructor</h1>
        <li>creates and initializes a new Array exotic object when called as a constructor.</li>
        <li>also creates and initializes a new Array object when called as a function rather than as a constructor. Thus the function call `Array(&hellip;)` is equivalent to the object creation expression `new Array(&hellip;)` with the same arguments.</li>
        <li>is a function whose behaviour differs based upon the number and types of its arguments.</li>
-        <li>is designed to be subclassable. It may be used as the value of an `extends` clause of a class definition. Subclass constructors that intend to inherit the exotic Array behaviour must include a `super` call to the Array constructor to initialize subclass instances that are Array exotic objects. However, most of the `Array.prototype` methods are generic methods that are not dependent upon their *this* value being an Array exotic object.</li>
+        <li>may be used as the value of an `extends` clause of a class definition. Subclass constructors that intend to inherit the exotic Array behaviour must include a `super` call to the Array constructor to initialize subclass instances that are Array exotic objects. However, most of the `Array.prototype` methods are generic methods that are not dependent upon their *this* value being an Array exotic object.</li>


The same, subclassing Array is really an important feature in ES6, why discourage that

I disagree? I guess it depends on what you mean by subclassing, since in JS it encompasses stuff like species construction, and that methods can deal with non-Array objects that still have the Array exotic objects' slots and essential methods.

What about subclassing Arrays is important beyond being able to extend them?

Jack-Works · 2021-03-26T03:16:52Z

spec.html

@@ -34249,7 +34249,7 @@ <h1>The Map Constructor</h1>
        <li>is the initial value of the *"Map"* property of the global object.</li>
        <li>creates and initializes a new Map object when called as a constructor.</li>
        <li>is not intended to be called as a function and will throw an exception when called in that manner.</li>
-        <li>is designed to be subclassable. It may be used as the value in an `extends` clause of a class definition. Subclass constructors that intend to inherit the specified Map behaviour must include a `super` call to the Map constructor to create and initialize the subclass instance with the internal state necessary to support the `Map.prototype` built-in methods.</li>
+        <li>may be used as the value in an `extends` clause of a class definition. Subclass constructors that intend to inherit the specified Map behaviour must include a `super` call to the Map constructor to create and initialize the subclass instance with the internal state necessary to support the `Map.prototype` built-in methods.</li>


Same as Array/Set/Error case

Same question as above then: what about the subclassing facilities, aside from being able to extend Maps, is important?

Jack-Works · 2021-03-26T03:19:27Z

In my personal programming use case, I have subclasses the following classes and found they're really useful. I don't think we should discourage those classes to be extended.

Array
Error
Map
Set
WeakMap
WeakSet

bakkot · 2021-03-26T04:08:59Z

Many of these were originally designed to be subclassable. All of them work to at least some extent in an extends clause (though good luck extending Function if you might be running on webpages with CSP). Some of them it makes more sense to subclass, others less, though exactly which and to what extent will depend on your point of view.

However, we aren't obligated to mention everything design decision we've ever made. My preference is to just drop mention of subclassing from all built-in constructors. We don't need to take a position on whether it's a good idea to subclass these, whether in general or for some particular subset. We can simply not discuss it at all.

ljharb · 2021-03-26T04:10:18Z

I think it’s very important that we actively discourage subclassing of the things that aren’t meant for it. I’m not sure how to do that without explicitly mentioning that some things are meant for it.

ptomato · 2021-03-26T18:27:28Z

Personally I agree with @bakkot here: removing the phrase doesn't discourage subclassing. But I'm not an editor, so having given my opinion I'll happily change this to reflect whatever comes out of the discussion, and then change Temporal accordingly.

ljharb · 2021-03-26T18:38:24Z

I think this goes beyond a purely editorial question, personally, since user expectations from prose in the spec do often impact normative behaviors - just like the same discussion around Temporal.

syg · 2021-03-31T01:49:29Z

Strong agree with @bakkot. "Subclassing" as an umbrella term encompasses several mechanisms, some of which I actively despise, and some of which are fine. I like this PR in that it calls out a particular mechanism as being actively maintained for future evolution of the language, and removing encouragement for using the whole set of mechanisms.

@ljharb and @Jack-Works, if you feel some of those mechanisms should be encouraged, then let's discuss those. I'm otherwise willing to die on the hill of removing blanket encouragement of "subclassing".

Jack-Works · 2021-03-31T01:59:04Z

"Subclassing" as an umbrella term encompasses several mechanisms, some of which I actively despise, and some of which are fine.

do you mean https://github.com/tc39/proposal-rm-builtin-subclassing#taxonomy-of-subclassing?

ljharb · 2021-03-31T03:53:15Z

@syg I'm not attached to the term "subclassing" for the precise reason you mention - that it conflates multiple mechanisms. I think it is important to explicitly distinguish the builtins that can meaningfully be the RHS of an extends - either by calling them out, or by calling out the rest. Simply removing the terminology leaves us in the same unfortunate position we're in now: users receive no guidance as to which builtin subclasses make sense (even if only a little) and which make zero sense.

bathos · 2021-03-31T16:45:19Z

I agree with @bakkot that this is very subjective and it's apparent that people don't share the same definition of "subclass". Some of it is provably untrue ("must include a super call"). Why replace one iffy/fuzzy text with an iffier, fuzzier one?

syg · 2021-03-31T21:07:23Z

do you mean https://github.com/tc39/proposal-rm-builtin-subclassing#taxonomy-of-subclassing?

Yes.

syg · 2021-03-31T21:08:25Z

I agree with @bakkot that this is very subjective and it's apparent that people don't share the same definition of "subclass". Some of it is provably untrue ("must include a super call"). Why replace one iffy/fuzzy text with an iffier, fuzzier one?

What's being replaced? This PR drops the "designed to be subclassable" language, the other language is existing.

bathos · 2021-04-01T12:08:44Z

@syg You’re right, sorry — that stemmed from misreading. The real changes here seem like improvements to me.

ptomato · 2021-05-14T00:00:37Z

Have the editors had a chance to discuss this? It seems like it is blocked on whether the removal of the phrase "is designed to be subclassable" is interpreted as a deprecation, or as a neutral removal of encouragement.

bakkot · 2021-06-09T22:38:52Z

Editors discussed this and are happy about it as-is among ourselves. Since there seems to be disagreement about whether this is strictly an editorial decision, I've put together a very short presentation and will ask that we get consensus on this particular change at the next meeting, emphasizing that a.) this PR does not take a position against (or for) subclassing any particular constructors and b.) the current state of affairs, which says that Boolean is "designed to be subclassable", is silly. If people want to call out some particular subset as being "designed to be subclassable", and/or call out some other subset as explicitly not for subclassing, they are welcome to drive that through committee as a followup.

allenwb · 2021-06-10T01:24:06Z

which says that Boolean is "designed to be subclassable", is silly.

"designed to be subclassable" was used in the ES6 specification with a very specific meaning:

if the constructor is correctly super invoked by a subclass constructor
- subclass instances will be the same kind of ordinary/exotic object as those created by the "superclass" constructor
- subclass instances will have the same internal slots as defined by the "superclass"
- prototype methods defined by the "superclass" that have dependencies upon internal slots or exotic internal methods will function correctly when invoked upon subclass instances

ES6 Boolean was, in fact, "defined to be subclassable" exactly according to those criteria. Specifically, Boolean.prototype.toString and valueOf are specified such that they make use of [[BooleanData]] internal slot of a Boolean subclass.

There may be very little utility in subclassing Boolean, but if somebody does it will work. The incorrect operation of ad hoc subclasses of Array and other builtins was something that developers complained about in the ES3/ES5 era. Fixing that general problem was an ES6 objective. For both internal and external consistency "defined to be subclassable" was the default design principle for ES6 builtins, even with there was minimal utility in subclassing some builtins. Only in a few cases such as Symbol, were there strong reasons to violate the consistency and design principle and make a builtin non-"subclassable".

Because "designed to be subclassable" was the ES6 norm, that label arguably was not need on every builtin constructor. But as a change from prior editions of the specification the label served as an important notice to both ES implementors and developers. Perhaps it is no longer needed, but the fact that has been this ongoing discussion make me think it still has value.

bakkot · 2021-06-10T01:38:40Z

@allenwb, thanks for giving the history. It's the opinion of the current editor group that the sense of "designed to be subclassable" used in your comment is adequately captured by the "may be used as the value of an extends clause of a class definition" part, which will remain. The advantage of removing specifically the "subclassable" part is that some people read it to imply more things than are present in the definition you intended (for example, people have read it as implicitly encouraging subclassing of built-ins, rather than merely noting that it would work).

As discussed during the March 2021 plenary, this note on "is designed to be subclassable" can be read as an encouragement or value judgement on whether it is desirable to subclass built-in classes like Boolean. We don't want to actively encourage this.

See tc39/ecma262#2360 Bring the language around this in line with the main ECMA-262 text, using the same unordered list form and the same bullet points everywhere.

As discussed during the March 2021 plenary, this note on "is designed to be subclassable" can be read as an encouragement or value judgement on whether it is desirable to subclass built-in classes like Boolean. We don't want to actively encourage this.

ljharb added the editorial change label Mar 25, 2021

ljharb reviewed Mar 25, 2021

View reviewed changes

Jack-Works reviewed Mar 26, 2021

View reviewed changes

bakkot added the editor call to be discussed in the next editor call label Mar 26, 2021

bakkot removed the editor call to be discussed in the next editor call label Apr 14, 2021

jugglinmike mentioned this pull request Jun 4, 2021

ArrayBuffer.prototype.transfer's lack of support for subclassing tc39/proposal-resizablearraybuffer#48

Closed

michaelficarra added the editor call to be discussed in the next editor call label Jun 8, 2021

bakkot mentioned this pull request Jun 9, 2021

Add ecma262#2360 tc39/agendas#1007

Merged

bakkot removed the editor call to be discussed in the next editor call label Jun 16, 2021

ljharb force-pushed the master branch 2 times, most recently from 1320e04 to 3d0c24c Compare June 29, 2021 02:17

ljharb force-pushed the master branch from 3d0c24c to 7a79833 Compare June 29, 2021 02:21

ljharb added the has consensus This has committee consensus. label Jul 13, 2021

jridgewell mentioned this pull request Jul 14, 2021

July 2021 babel/proposals#75

Open

bakkot approved these changes Jul 14, 2021

View reviewed changes

michaelficarra approved these changes Jul 15, 2021

View reviewed changes

michaelficarra added the ready to merge Editors believe this PR needs no further reviews, and is ready to land. label Jul 15, 2021

ljharb force-pushed the designed-to-be-subclassable branch from 1c01ea5 to a44f010 Compare July 15, 2021 03:38

ljharb merged commit a44f010 into tc39:master Jul 15, 2021

ptomato deleted the designed-to-be-subclassable branch July 15, 2021 03:52

ptomato mentioned this pull request Jul 23, 2021

Editorial: Remove "designed to be subclassable" tc39/proposal-temporal#1677

Merged

	<li>may be used as the value of an `extends` clause of a class definition.</li>
	<li>may be used as the value of an `extends` clause of a class definition, but is not intended to be subclassed.</li>

Editorial: Remove 'designed to be subclassable' #2360

Editorial: Remove 'designed to be subclassable' #2360

Conversation

ptomato commented Mar 25, 2021

ptomato commented Mar 25, 2021

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

zloirock Jul 23, 2021 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Jack-Works commented Mar 26, 2021

bakkot commented Mar 26, 2021 • edited Loading

ljharb commented Mar 26, 2021

ptomato commented Mar 26, 2021

ljharb commented Mar 26, 2021

syg commented Mar 31, 2021 • edited Loading

Jack-Works commented Mar 31, 2021

ljharb commented Mar 31, 2021

bathos commented Mar 31, 2021

syg commented Mar 31, 2021

syg commented Mar 31, 2021

bathos commented Apr 1, 2021

ptomato commented May 14, 2021

bakkot commented Jun 9, 2021 • edited Loading

allenwb commented Jun 10, 2021

bakkot commented Jun 10, 2021

zloirock Jul 23, 2021 •

edited

Loading

bakkot commented Mar 26, 2021 •

edited

Loading

syg commented Mar 31, 2021 •

edited

Loading

bakkot commented Jun 9, 2021 •

edited

Loading