Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.
Sign upsuper in class extending null should disallow super call in constructor #698
Comments
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
bterlson
Sep 28, 2016
Member
I'm also not entirely sure why we didn't make super in base class methods an early error (rather than a TypeError by way of MakeSuperPropertyReference). @allenwb thoughts?
|
I'm also not entirely sure why we didn't make super in base class methods an early error (rather than a TypeError by way of MakeSuperPropertyReference). @allenwb thoughts? |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
bakkot
Sep 28, 2016
Contributor
@bterlson, given that it works in object literals, it would be at least a little surprising if didn't work in base classes.
e.g.
''+(new class {
toString(){
return 'my ' + super.toString();
}
}); // "my [object Object]"|
@bterlson, given that it works in object literals, it would be at least a little surprising if didn't work in base classes. e.g. ''+(new class {
toString(){
return 'my ' + super.toString();
}
}); // "my [object Object]" |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
bterlson
Sep 28, 2016
Member
@bakkot right, thanks!
So presumably we could make super in methods for class extends null an early error?
|
@bakkot right, thanks! So presumably we could make super in methods for |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
bterlson
Sep 28, 2016
Member
@ajklein points out that [[HomeObject]]'s prototype is determined dynamically, so the prototype could change.
|
@ajklein points out that [[HomeObject]]'s prototype is determined dynamically, so the prototype could change. |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
bakkot
Sep 28, 2016
Contributor
Are we talking about the literal null, vs e.g. class extends (()=>null)() {}? Because as I understood it ClassHeritage could evaluate to null at runtime - but we can't have early errors for that.
|
Are we talking about the literal |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
ljharb
Sep 28, 2016
Member
Thanks to @ajklein my understanding is now that if [[HomeObject]] ever became changeable, which was previously possible, that extends X could always change from null to non-null, so super access can't be an early error.
|
Thanks to @ajklein my understanding is now that if |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
bterlson
Sep 28, 2016
Member
@bakkot yeah you're right, early error is only possible with the null literal (unless we throw early-ish during CDE, but I wouldn't argue for that I guess).
|
@bakkot yeah you're right, early error is only possible with the |
bterlson commentedSep 28, 2016
It presently keys off of ClassHeritage being present but if it's present but null it should also be an early error. /cc @bmeck