Class Inheritance is Not ES6 Spec Compliant

[EisenbergEffect]

The following should log true but logs false instead:

class Foo {}
class Bar extends Foo {}

console.log(Object.getPrototypeOf(Bar) === Foo);

This is due to how the __extends helper is implemented. It generates this:

var __extends = this.__extends || function (d, b) {
    for (var p in b) if (b.hasOwnProperty(p)) d[p] = b[p];
    function __() { this.constructor = d; }
    __.prototype = b.prototype;
    d.prototype = new __();
};

An example of a correctly functioning extends implementation can be found in the 6to5 compiler. Here is their implementation:

var _extends = function (child, parent) {
    child.prototype = Object.create(parent.prototype, {
      constructor: {
        value: child,
        enumerable: false,
        writable: true,
        configurable: true
      }
    });
    child.__proto__ = parent;
  };

[basarat]

(Object.getPrototypeOf(Bar) === Foo);

All that's really missing is child.__proto__ = parent;, so I would recommend:

var __extends = this.__extends || function (d, b) {
    d.prototype.__proto__ = b.prototype;
    d.__proto__ = b;
};

---

Notes:

• for (var p in b) if (b.hasOwnProperty(p)) d[p] = b[p]; was needed for statics. This is overcome by d.__proto__ pointing to the base.
• d.prototype.__proto__ = b; if you are using __proto__ why not go all the (unsafe) way.
• Object.create the team didn't use this to support ES3.

[basarat]

Verified that it should indeed be true by the following code run on the console of an ES6 enabled browser (e.g. chrome://flags/#enable-javascript-harmony) :

(function (){"use strict"; class Foo{}; class Bar extends Foo{}; console.log(Object.getPrototypeOf(Bar) === Foo);})() 

prints true

[Arnavion]

__proto__ was not standardized until ES6. IE, FF, V8 and JavaScriptCore atleast support it but maybe there are some ES5 browsers out there that don't?

[basarat]

I am not so sure about IE (note IE10):

[Arnavion]

Hmm, indeed. Only IE11 supports setting __proto__.

[Arnavion]

I guess we could take 6to5's shim and add TS's static-copying code to it? Then it would start giving the correct answer for Object.getPrototypeOf(Derived) on browsers which do support __proto__, and statics will continue to be copied on browsers which don't.

var __extends = function (d, b) {
    d.prototype = Object.create(b.prototype, {
        constructor: {
            value: d,
            enumerable: false,
            writable: true,
            configurable: true
        }
    });

    d.__proto__ = b;

    for (var p in b) if (b.hasOwnProperty(p)) d[p] = b[p];
};

Setting __proto__ is still bad for performance though - getting standardized didn't change that.

---

I would say that requiring Object.getPrototypeOf(Derived) === Base is a relatively uncommon operation to require this change in the default emit. If user desires it, they can provide their own implementation to override the default one.

[basarat]

@Arnavion I like this solution. I think ES3 support should be dropped, as having a enumerable constructor on ES5 browsers with the current extends was always ugly.

[Arnavion]

Well, I was only suggesting that for the ES5 emit. TS could keep the existing emit for ES3.

But anyway, as I said I'm not a fan of mutating __proto__, so I don't support it becoming the default emit. I think the user should provide that implementation of __extends on their own if they really want that behavior (or just the 6to5 one if they don't care about Object.getPrototypeOf(Derived) on old IE).

[EisenbergEffect]

So, the reason I brought this up is because it relates to annotations. I'm writing a library for working with AtScript metadata annotations. Annotations are stored directly on the function that they annotate. On some occasions you want to search the class hierarchy for any annotations of a certain type. To do this, you need to use Object.getPrototypeOf(Derived) recursively until you find the annotation you are looking for or hit null. If/when TypeScript adds annotations, and developers want to start working with them, there will be a greater need to handle this.

For my own case, I am only targeting Evergreen browsers, so old IE and ES3 are not a concern of mine.

[basarat]

to support all browsers perhaps we should use inherits (https://github.com/isaacs/inherits/blob/master/inherits_browser.js same as the core node.js util module).

Nevertheless just a suggestion as a meantime thing @EisenbergEffect you might use this inherits instead of extends and use super_ to walk up the chain.

[Arnavion]

@basarat I think @EisenbergEffect could just use the 6to5 shim he provided if he wanted to override __extends.

Also, utils.inherit() (and that browser version) doesn't inherit statics, so it's not a drop-in replacement for __extends. If you added static-copying to it, it would basically become if (Object.create) { /* 6to5 shim code */ } else { /* TS shim code */ } which would still break on old IE.

[EisenbergEffect]

Is there currently a way to plug in a custom __extends implementation for the TypeScript compiler? I don't need it myself but I'd like to be able to tell developers using my framework how best to get the standard behavior when using TypeScript if they need it.

[Arnavion]

Since the default emit is var __extends = this.__extends || ..., if you provide a function named __extends on the global object before the TS-emitted __extends, your function will be used instead. This is a deliberate escape hatch to let users plug in their own implementation.

If you want to do it in TS itself along with the original code, then put a var __extends = function (d, b) { ... }, that is, without the this.__extends || part, to forcibly override. Example

[basarat]

Is there currently a way to plug in a custom __extends implementation for the TypeScript compiler

A hacky almost working suggestion perhaps in an npm es6-extend:

var root = global || window; 
root.__extends = function(d,b){/*your code*/}

Now require('es6-extend') at the root of your project just once will fix it for all files.

Note: I haven't tested the code but I say almost because the default __extends uses this.__extends and this in node isn't global, its the current module.

[Arnavion]

Perhaps I should open a bug to get the team to not have this.__extends and instead just use __extends (which will look at global on node and window on browser).

var __extends = __extends || ... will not work. It will just get undefined for the first expression even if there's already a global __extends, since its own (uninitialized) definition is in scope, so it'll always assign to __extends. Even global || window will not work if global is undeclared, since it's a TypeError to refer to undeclared variables.

You could ask for the TS emit to become

var __root = typeof global !== "undefined" && global || typeof window !== "undefined" && window || this;
var __extends = __root.__extends = __root.__extends || ...

Unfortunately the only real solution to get the global object instead of hard-coding a list of possible globals is via eval var __root = (1, eval)("this");. Maybe this isn't a big deal though.