Ecma262: extends null

Created on 14 Apr 2016  路  6Comments  路  Source: tc39/ecma262

It does not allow me to sleep for a year. It was broken after the last class reform. See the last sentence. For usage this should be called super, but we can't call null. This issue was closed. Now added many serious changes for ES6, so maybe makes sense fix extends null like it was proposed in #22? Usage this in extended from null constructors without super or a special case for super in those constructors should not break any current code, but should make extends null useful instead of current useless garbage in the spec.

Most helpful comment

@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.

All 6 comments

@zloirock not sleeping is definitely a bug. We should fix this. I think @allenwb's suggestion in #22 is sound (modulo early error restrictions, but I'm not seeing any).

@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);

I agree. I think it is a specification bug that extend null classes were marked as "derived"

@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.

Yep, good catch, overlooked it (and fixed via a35f0f3). I don't think super makes sense here since there is no super constructor.

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?

Was this page helpful?
0 / 5 - 0 ratings