BUG: getters, setters and inheritance

[endel]

TypeScript Version: 2.1.4

Code

class Base {
    _height: number;
    public set height (value: number) {
        this._height = value;
    }
}

class Intermediary extends Base {
    public get height () {
        return this._height;
    }
}

class Concrete extends Intermediary {
    constructor () {
        super();
        this.height = 10;
    }
}

let c = new Concrete();
console.log(c.height);

Expected behavior:

Should output 10.

Actual behavior:

• TypeScript error: "Cannot assign to 'height' because it is a constant or a read-only property."
• Generated JavaScript file outputs undefined.

The problem here is that the Intermediary class is overwriting the set method. I've changed the output .js file to fix this issue, and it looked like this: (using getOwnPropertyDescriptor on parent's prototype to keep the set reference.)

var Intermediary = (function (_super) {
    __extends(Intermediary, _super);
    function Intermediary() {
        return _super.apply(this, arguments) || this;
    }
    Object.defineProperty(Intermediary.prototype, "height", {
        set: Object.getOwnPropertyDescriptor(_super.prototype, "height").set,
        get: function () {
            return this._height;
        },
        enumerable: true,
        configurable: true
    });
    return Intermediary;
}(Base));

[mhegazy]

This behaves in accordance to the ES6 spec. By defining a getter you take the slot on Intermediary, the lookup the prototype chain will stop there, regardless it has a setter or not.

You can see the same behavior in an engine supporting ES6; here is the output of my Chrome:

[endel]

Thanks for the clarification @mhegazy. Would it ever be possible to extend TypeScript to support edge cases like this? Also emitting a different JavaScript code sometimes can be really helpful.

[mhegazy]

Thanks for the clarification @mhegazy. Would it ever be possible to extend TypeScript to support edge cases like this? Also emitting a different JavaScript code sometimes can be really helpful.

this is not an edge case, this is a behavior clearly not allowed by the JS spec. TypeScript aims to be a super set of JS, that entails following the spec.

[irfaanc]

Could we at least get a compiler error or a warning? This current behavior is inconsistent with how typescript otherwise behaves. The closest analogous behavior is when both the base and subclass both contain the same private member. Rather than letting broken behavior silently slip through, the typescript compiler throws a compiler error (TS2415).

[mhegazy]

This current behavior is inconsistent with how typescript otherwise behaves.

I do not see why this is the case.

Could we at least get a compiler error or a warning?

Issue #11596 tracks making this an error.

[irfaanc]

I do not see why this is the case.

I'm going to disagree, and use the example I provided when I made that assertion (Typescript throwing an error when an instance property would otherwise be silently invalidated). Unless you're interpreting that statement differently? I have difficulty believing the Typescript team believes letting something silently fail is consistent with the overall experience you're working to achieve.

Issue #11596 tracks making this an error.

From my read, #11596 is tracking a separate issue and separate concept - removing the ability the define just a setter (which, incidentally, I'm not fond of - I like the symmetry of readonly and writeonly properties, and agree with Igorbek's use-site variance argument).

I opened up issue #13669 to track the opposite version of the underlying issue endel hit - having a get in the a base class invalidated by a set in a subclass. It's the same underlying problem - the subclass's defineProperty() removing the base classes property definition.

#13669 got duped to this (#13432). Which Is reasonable, if this is tracking that general problem. But if this bug is "merely" tracking disabling set-only accessors (which appears to still be actively debated), this isn't the same concept.

But, if you disagree with the previous assertion, shouldn't this be duped against #11596, rather than flagged Working as Intended?