> Le 25 déc. 2013 à 03:41, Sebastian Markbåge <sebastian at calyptus.eu> a écrit :
> 
> This is an esoteric and ugly use case but I'm not trolling. The default constructor for a class which extends another is:
> 
> constructor(...args){ super(...args); }
> 
> Is there any reason it shouldn't return the value from super?
> 
> constructor(...args){ return super(...args); }
> 
> Basic constructors still have the quirky behavior of ES functions that they can return any object and don't have to return the instantiated object. This can be useful if they're used as functions or should return a placeholder object, or other instance, for compatibility/legacy reasons. E.g. when you have a custom instantiation process.
> 
> class Foo { constructor() { return {}; } }
> 
> Currently, this behavior doesn't carry over to subclasses by default:
> 
> class Bar extends Foo {	}
> 
> You'd have to explicitly define a constructor that returns the value from the super call.

I agree that `constructor(...args){ return super(...args); }` is better (i.e. less surprising) when the super-class's constructor returns an other object than `this`. However, under the current state of the specification, there is at least one exception: the `Object` constructor ignores its `this` value and creates a fresh object, which is unwanted in the theoretical case you define a class extending explicitly `Object`. I guess that this case could be normalised by using a similar mechanism as `Array` and its [[ArrayInitialisationState]] internal slot?

> 
> Additionally, since DefineMethod is going to be exposed, does it make sense to expose ReferencesSuper too?
> 
> Otherwise there is no way to detect, at runtime, if a default constructor function is a top-level constructor (without a super), or a subclass with a super. One of them can use toMethod but not the other.
> 

Since I haven't yet seen any formal definition of `toMethod`, I don't what is its intended behaviour on methods that don't reference `super`. I think that the most reasonable behaviour, in that case, is to just clone the function: for it would allow to refactor transparently methods, removing or re-adding references to `super` without needing to adapt the code around them.

—Claude

I agree that `constructor(...args){ return super(...args); }` is better (i.e. less surprising) when the super-class's constructor returns an other object than `this`. However, under the current state of the specification, there is at least one exception: the `Object` constructor ignores its `this` value and creates a fresh object, which is unwanted in the theoretical case you define a class extending explicitly `Object`. I guess that this case could be normalised by using a similar mechanism as `Array` and its [[ArrayInitialisationState]] internal slot?

> 
> Additionally, since DefineMethod is going to be exposed, does it make sense to expose ReferencesSuper too?
> 
> Otherwise there is no way to detect, at runtime, if a default constructor function is a top-level constructor (without a super), or a subclass with a super. One of them can use toMethod but not the other.
> 

Since I haven't yet seen any formal definition of `toMethod`, I don't what is its intended behaviour on methods that don't reference `super`. I think that the most reasonable behaviour, in that case, is to just clone the function: for it would allow to refactor transparently methods, removing or re-adding references to `super` without needing to adapt the code around them.