Not forcing super in derived class's constructor?
curvedmark at gmail.com
Wed May 13 13:15:02 UTC 2015
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."
> 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).
More information about the es-discuss