Not forcing super in derived class's constructor?
brendan at mozilla.org
Wed May 13 08:51:02 UTC 2015
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
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
> 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