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 upextends null #543
Comments
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
zloirock
Apr 14, 2016
@bterlson special case for usage super in those constructors should remove early error and default constructor issues:
var this = Parent !== null ? Reflect.construct(Parent, args, new.target) : Object.create(new.target.prototype);
zloirock
commented
Apr 14, 2016
•
|
@bterlson special case for usage var this = Parent !== null ? Reflect.construct(Parent, args, new.target) : Object.create(new.target.prototype); |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
allenwb
Apr 14, 2016
Member
I agree. I think it is a specification bug that extend null classes were marked as "derived"
|
I agree. I think it is a specification bug that |
mysticatea
referenced this issue
Apr 17, 2016
Closed
constructor-super - super() must be called even if the class extends null #5449
This was referenced Apr 19, 2016
bterlson
closed this
in
98c67f2
Apr 19, 2016
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
loganfsmyth
Apr 19, 2016
Contributor
@bterlson Assuming I'm following this right, this still means the existing spec behavior of
class Foo extends null {
constructor(){
super();
}
}
will throw because super() can't be used in an extends null class, correct? If so, it seems like step 10 should also be updated, since this will now initialize this by default, but still default to calling super() when no constructor is given.
I'll admit, auto-initializing this seems unfortunate to me though, it seems much more consistent to always require super() to initialize this even in cases where it is null, since "use super() when you have extends" is a more straightforward thing to understand from an end-user stand-point.
|
@bterlson Assuming I'm following this right, this still means the existing spec behavior of
will throw because I'll admit, auto-initializing |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
bterlson
Apr 19, 2016
Member
Yep, good catch, overlooked it (and fixed via a35f0f3). I don't think super makes sense here since there is no super constructor.
|
Yep, good catch, overlooked it (and fixed via a35f0f3). I don't think super makes sense here since there is no super constructor. |
added a commit
to bocoup/test262
that referenced
this issue
May 30, 2016
added a commit
to bocoup/test262
that referenced
this issue
May 30, 2016
added a commit
to bocoup/test262
that referenced
this issue
May 30, 2016
jugglinmike
referenced this issue
May 30, 2016
Merged
Update tests concerning null-extending classes #658
added a commit
to tc39/test262
that referenced
this issue
Jun 10, 2016
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
littledan
Jun 16, 2016
Member
The change here makes sense to me, but I missed this thread until the test262 test went in and V8 failed it. I'm wondering, for normative changes like this, would it make sense to summarize them at TC39 (or some other place which really highlights it), and get some implementation feedback (or documentation that an implementation already does this) before committing?
|
The change here makes sense to me, but I missed this thread until the test262 test went in and V8 failed it. I'm wondering, for normative changes like this, would it make sense to summarize them at TC39 (or some other place which really highlights it), and get some implementation feedback (or documentation that an implementation already does this) before committing? |
zloirock commentedApr 14, 2016
•
edited
It does not allow me to sleep for a year. It was broken after the last class reform. See the last sentence. For usage
thisshould be calledsuper, but we can't callnull. This issue was closed. Now added many serious changes for ES6, so maybe makes sense fixextends nulllike it was proposed in #22? Usagethisin extended fromnullconstructors withoutsuperor a special case forsuperin those constructors should not break any current code, but should makeextends nulluseful instead of current useless garbage in the spec.