Not forcing super in derived class's constructor?

[Brendan Eich]

Glen Huang wrote:
>> maybe subclassing that particular class is not the correct 
>> abstraction here;
>
> I think the need for inheriting methods and the need for a totally 
> different way of preparing the object are orthogonal.

There's a saying taught (I'm told) in law school: "hard cases make bad 
law."

It means systems of laws (real world or JavaScript language laws) must 
aim for the common cases and avoid both over-prescribing or 
over-reaching, *and* trying to cover all use-cases with all affordances. 
You can't "have it all", in short.

Your case seems hard, at a glance. If you can show it's common, please 
cite evidence.

> I wonder what's so terrible about creating a new object when there is 
> no super that you just want to avoid it?

Your proposal was:

"TLDR: If `this` is used without `super` (which should be statically 
analyzable), let it refer to Object.create(new.target.prototype). 
Otherwise, let super creates what it refers to."

I think you meant "If `this` is used without `super` in a subclass 
constructor (a subclass has an `extends` clause; this condition should 
be statically analyzable), let it refer to 
Object.create(new.target.prototype). Otherwise, let super creates what 
it refers to.


We discussed this in the long course of coming to ES6 classes, if I 
recall correctly. What you propose makes a footgun. It's too easy to 
forget to call super and get an object that isn't correctly initialized. 
What you want to do, bypass the super-constructor but wire up the 
proto-chain, can be done the hard way, appropriate for a hard case 
(which makes bad law).

/be