Not forcing super in derived class's constructor?

[Glen Huang]

Thanks for the motto. Another TIL. :)

My proposal is based on the assumption that people didn't complain much about it's easy to forget calling super in es5 code.

But I think you are right, preventing footgun is more important than catering to a hard case.

> On May 13, 2015, at 4:51 PM, Brendan Eich <brendan at mozilla.org> wrote:
> 
> 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