Default constructor and extends null
Erik Arvidsson wrote:
At the face to face meeting we agreed that if no constructor is present in a class a default one is provided as if the following constructor was present.
class C extends null { constructor(...args) { super(...args) } }
What should this do when C extends null? If this was manually added I would prefer that this would be a runtime error.
Agreed. Allen probably has a thought. I think we just did not discuss this case, or overlooked it.
Should we special case this and use an empty constructor if the super class is null?
+1.
On Tue, Jul 31, 2012 at 10:56 PM, Brendan Eich <brendan at mozilla.org> wrote:
Agreed. Allen probably has a thought. I think we just did not discuss this case, or overlooked it.
+1.
Good. That is what I ended up implementing.
On Jul 31, 2012, at 9:46 PM, Erik Arvidsson wrote:
At the face to face meeting we agreed that if no constructor is present in a class a default one is provided as if the following constructor was present.
class C extends null { constructor(...args) { super(...args) } }
What should this do when C extends null? If this was manually added I would prefer that this would be a runtime error. Should we special case this and use an empty constructor if the super class is null?
This is covered by the runtime semantics of super in the current spec. draft.
In 11.2.4, see line 5 of the third algorithm which says: 5. ReturnIfAbrupt(CheckObjectCoercible(baseValue)).
CheckObjectCoercible throws a TypeError if baseValue is null. In this algorithm, baseValue is provided by the GetSuperBase algorithm 10.2.1.3.4 which pretty much reduces to returning the [[Prototype]] value of the object (in this case C.prototype) that the enclosing method is super bound with. that value will be null in this case.
I don't think we want to try to issue an early error for explicit cases such as the above. However, considering that [[Prototype]] chains are mutable, I don't think we should.
I forget the second question, regarding empty constructors.
On Jul 31, 2012, at 9:46 PM, Erik Arvidsson wrote:
...
Should we special case this and use an empty constructor if the super class is null?
Yes, seem necessary. The default definition used for an empty constructor would then be something like:
constructor(...args) { try {super.constructor} catch (e) {return}; super(...args); }
In the actual specification, I wouldn't use an exception but instead use the internal GetSuperBase operation in the guard.
At the face to face meeting we agreed that if no constructor is present in a class a default one is provided as if the following constructor was present.
class C extends null { constructor(...args) { super(...args) } }
What should this do when C extends null? If this was manually added I would prefer that this would be a runtime error. Should we special case this and use an empty constructor if the super class is null?
At the face to face meeting we agreed that if no constructor is present in a class a default one is provided as if the following constructor was present. class C extends null { constructor(...args) { super(...args) } } What should this do when C extends null? If this was manually added I would prefer that this would be a runtime error. Should we special case this and use an empty constructor if the super class is null? -- erik