Not forcing super in derived class's constructor?

[Glen Huang]

Thanks for the reply.

> it is IMHO a good thing

I like the way you call the old way of doing things clunky and "super" shiny (no sarcasm intended). :)

However, forcing super has one major drawback: it becomes cumbersome when you don't want to call superclass's constructor(), that you want to define a new constructor() to override it.

When that happens, you have two choices:

1. don't use "this", create a new object and return it.
2. use the old way to create "class"

#1 is against humanity. It's like a new law enforces that if your grandma is near by and you only want to talk your mom, you are forbidden to call her mom, otherwise you will be thrown off a bridge.

#2 is deprecated. For example, it doesn't correctly set enumerability unless you do it explicitly.

> I don't see personally the point to support deprecated patterns

I agree the function pattern should be deprecated, but not the concept of "you will be given a shiny new object when the constructor is called".

In the case of my proposal, it becomes "you will be given a shiny new object when the constructor is called unless you call super in it, which creates a shiny new object itself".

I think it a lot reasonable than "you must use super to get the new object, if you don't want to trigger its side effects, create the object yourself but you can't call it 'this' like you accustom to." unless I missed something and it's possible to use "this".

But I still feel automatically creating a new regular object if no super is called makes life a lot easier.