Misleading proposal name?

[bathos]

I've read through this in the past and just reviewed it again. While I share a lot of concerns others have raised, I think the current name of the proposal is making it look like a significantly more alarming investigation/proposal than it is. As far as I can tell, what is being proposed is removing or reducing the number of special internal-to-a-builtin-algorithm "contractual" hooks that facilitate certain subclassing patterns. It does not appear that this proposal seeks to remove builtin subclassing at all, though, and pretty much everything currently possible would remain possible (but would require additional explicit method shadowing etc.)

tldr you're scaring people :)

[syg]

Suggestions? "Reduce builtin subclassing"?

[bathos]

I think “built-in subclassing” without further qualification implies, for many folks (though I could be mistaken), the actual act of using a built-in constructor as the heritage of a derived class. So initially it may appear that this proposal is about removing the ability to do e.g. class extends Array {} successfully altogether.

The “built-ins” in question here though aren’t the constructors (afaict, modulo indirect cases like TypedArray honoring ArrayBuffer species maybe?) but various intrinsic methods whose algorithms honor generic unbranded contracts. And it’s not that those built-ins would be removed, but rather modified to no longer leverage these out-of-the-box hooks. So my understanding is that if e.g. @@species support were removed for TypedArray, I would need to modify my TypedArray subclasses to explicitly implement a local subarray() method, etc, but “a custom TypedArray subclass whose associated subarray method returns an instance of the custom subclass” remains possible; the consequence is mainly that we’d need some new explicit boilerplate to achieve certain behaviors that are currently “free”. (Is that roughly accurate?)

If that is accurate, then the things potentially being removed are “hooks” or “internal subclassing contracts” or something. AFAIK there’s no formal name for this concept, but I think phrasing like “remove custom subclassing hooks from built-ins” would make the scope of the proposed changes clearer and avoid raising alarm about subclassing itself becoming impossible.

It’s also notable I think that some existing built-in subclasses would not be impacted at all? I have e.g. written classes where static [Symbol.species] = TheRegularBuiltin; is the first member; it’s not really a given that the “spawned instances should be of the same subclass” is always the rational behavior. Arguably the default @@species accessors are already making an overbroad assumption about subclass semantics.

[syg]

I think “built-in subclassing” without further qualification implies, for many folks (though I could be mistaken), the actual act of using a built-in constructor as the heritage of a derived class. So initially it may appear that this proposal is about removing the ability to do e.g. class extends Array {} successfully altogether.

Ah I see. You're right, the intention here is in fact the opposite wrt extends, to continue supporting having builtins in heritage positions, with new.target and all that.

I guess "reduce builtin subclassing hooks" sounds pretty accurate.

[zloirock]

Renaming "let's kill JavaScript" to something else does not change the meaning. No one case of current Array, RegExp or Promise subclassing can't be removed without breaking something. Removing @@species support from new proposals, for example, Array methods without proposing an alternative means that those methods will not be subclassable and we will not be able to extend Array and just reuse all Array methods like

class ShoppingCart extends Array {
  constructor() { /* ... */ }
  checkout() { /* ... */ }
  display() { /* ... */ }
  // ...
}
// ...
cart = cart.filter(it => it.selected); // new ShoppingCart instance

Maybe you could propose a proper alternative for @@species subclassing, but without it it's a harmful proposal.

[bathos]

@zloirock I am very skeptical of most / maybe all of these changes being possible, too. It would certainly break existing code I’ve written, some of which I’m no longer in a position to update. Regardless, it’s valuable for people to be able to understand the nature of what changes are being proposed and, since it’s currently easy to misread I think, what changes aren’t being proposed. I don’t think “let’s kill JavaScript” would help with this :)

[zloirock]

@bathos I just mean that "rm-builtin-subclassing" describes this proposal good enough and the fact that it scares people is good.

[matthew-dean]

@zloirock Yeah this proposal is terrifying.