Unable to access extended properties in constructor

[brenthoneybone]

I'm not sure if this is an intention of typescript or not but acts differently to how I would've expected.

If i have a base class and extend it, overriding some base class properties, then want to work with the properties in the child class constructor I still access the parent properties.

This is shown in the below basic example.

class Base {

    public myVar:string = 'Base';

    public constructor() {
        console.log(this.myVar);
    }

}

class Child extends Base {

    public myVar:string = 'Child';

}

var base:Base = new Base(); // 'Base' - As expected
var child:Child = new Child(); // 'Base' - I would've expected this to be 'Child'

console.log(base.myVar); // 'Base' - As expected
console.log(child.myVar); // 'Child' - As expected

This happens in the compiled JS because the super is called before the child properties are set:

function Child() {
    _super.apply(this, arguments);
    this.myVar = 'Child';
}

Is this intended? An issue? Or a trade off because of JS limitations? Thanks!

Note that if I do something like this, it works as I would've expected. However it feels like a bit of a hacky work around.

class Base {

    public myVar:string = 'Base';

    public constructor() {
        this.setup();
    }

    protected setup() {
        console.log(this.myVar);
    }

}

class Child extends Base {

    public myVar:string = 'Child';

    public constructor() {
        super();
        this.setup();
    }

}

var base:Base = new Base(); // 'Base'
var child:Child = new Child(); // 'Child' - Now as expected

console.log(base.myVar); // 'Base'
console.log(child.myVar); // 'Child'

[RyanCavanaugh]

Edit: I've posted a longer exploration of this at http://stackoverflow.com/questions/43595943/why-are-derived-class-property-values-not-seen-in-the-base-class-constructor/43595944

This is the intended behavior.

The order of initialization is:

1. The base class initialized properties are initialized
2. The base class constructor runs
3. The derived class initialized properties are initialized
4. The derived class constructor runs

Why is this the order?

First, look closely at the JavaScript emitted for a class. There are only two places where code runs -- in the static initialization of the class (where the prototype is set up and static members are initialized), and in the constructor function for the class instance. Property initialization is injected into the first part of the constructor, which means that step 1 and step 2 are necessarily going to happen one after the other.

It's also clear that the base class constructor has to run before the derived class constructor.

This leaves us with only one alternative:

1. The derived class initialized properties are initialized
2. The base class initialized properties are initialized
3. The base class constructor runs
4. The derived class constructor runs

That ordering would result in very surprising behavior:

class Base {
    x = 'foo';
    getX() {
        return this.x;
    }
}
class Derived extends Base {
    m = this.getX(); // Would be 'undefined', not 'x'
    constructor() {
        super();
    }
}

[SimonCsoma]

I would expect that example to give an compile error because you would/should never use this in class variable declaration

I.E.:
protected m = this.getX();

[richardlawley]

I think it's worth noting that the behaviour of C# is exactly as the alternative mentioned above, i.e.

1. The derived class initialized properties are initialized
2. The base class initialized properties are initialized
3. The base class constructor runs
4. The derived class constructor runs

The example given that would result in "very surprising" behaviour is prevented by the compiler:

class Base {
    public string x = "foo";
    public string getX() {
        return x;   
    }
}

class Derived : Base {
    public string m = this.getX();   // CS000027 Keyword 'this' is not available in the current context
}

I suspect this is one of the reasons people keep raising this issue - programming in the style they're used to simply doesn't work in TS, and you have to use horrible workarounds to accomplish the same thing.

However, the TS declaration style requires being able to access this:

class Test {
    FirstName: string;
    Surname: string;
    FullName = () => `${this.FirstName} ${this.Surname}`;
}

EDIT: As pointed out, the above example would still be fine as it's a function. So I still think this issue is valid.

[gregtour]

This behavior seems like an unusual issue to confront.

[AlwinGarside]

However, the TS declaration style requires being able to access this:

class Test {
    FirstName: string;
    Surname: string;
    FullName = () => `${this.FirstName} ${this.Surname}`;
}

Just wanted to mention this example is accessing this in the context of a function, which should still work in the alternative behaviour.

[JoelLeach]

I'd like to add my vote for a solution that makes more sense to OOP veterans coming from other languages, whether it is for EcmaScript or TypeScript only. I wrote an article on the subject, including suggested workarounds.

[paishin]

To execute the Base constructor after Derived class values have been set I am including Base constructor's operations in a setTimeout function. Everything seems to work ok but I don't know what other implications this might have. Anyone with more knowledge can comment if this is a bad practice and why?

class Base {
    x = 'foo';
    constructor(){
       setTimeout(()=>{alert(this.x)},0);
    }
}
class Derived extends Base {
    x='bar';
    constructor() {
        super();
    }
}

new Derived(); //Alerts 'bar'

[vasa-c]

Sorry for my question.
But, still, it is a bug or a feature?

[paishin]

Its just the way TypeScript works

[mhegazy]

It is rather, how JavaScript (ES6) works.

[PMXScott]

This makes no sense what so ever in my view.

JS is prototypal. The object oriented community found it weird and came up with loads of hacks to simulate class based inheritance. In doing so there became lots of gotchas such as accidentally forgetting the "new" keyword, which in turn created more hacks. The JS comity finally decided to support the vast number of object oriented users of JS by adding in class support. However, they decided they didn't like being pressured into adding "normal" class based inheritance that most people would instantly understand (and assume) and so decided to follow the somewhat normal JS way of doing the occasional "wtf" implementation to trip up users ( https://martin-thoma.com/javascript-wtf/ https://www.smashingmagazine.com/2011/05/10-oddities-and-secrets-about-javascript/ http://charlieharvey.org.uk/page/javascript_the_weird_parts to name a few). Implementing sub class constructors in a way that most of the object oriented community will trip up on I guess is at least sticking with the core of the JS craziness! Shame though that TypeScript still follows that philosophy when it has so much of everything else right (in my opinion).

[SimonCsoma]

Adding to PMXScott their argument is that typescript usually perceived as a superset of ES6 which has a typical inheritance system.

The problem that comes forth from this inheritance that typescript implements is one where when a framework wants to have a class initialize some part of the system which also needs to be configurable on a class by class basis it will simply be ignored by the language. Thus using inheritance in these kinds of situations will demand a pretty weird structure.

I.E. Backbonejs is using an initialize function for its views. When one is extending from this view and wants to for example overwrite some auto rendering function (like implemented by the Chapin library) this will not be overwritten until after the initialization is complete.

Circumventing this, for now, is still possible by using the constructor of the class and passing them in an acrobatic way on as options to the base view. But with the support of ES6 classes will be less and less supported want IMHO will not encourage the use of typescript by instead will enforce developers to move away.

One might argue that typescript is meant for the smaller projects, but this, in my opinion, is not the case since type casing I the entire idea of the language and there for meant for larger project ergo for projects using frameworks.

These kinds of mistakes make me wonder if typescript will be a lasting language.

Edit: miss read mhegazy's comment