Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

property accessor of subclass instance should return base's class property value, but uses a subclass' getter #36399

Closed
abobr opened this issue Jan 24, 2020 · 6 comments
Labels
Question An issue which isn't directly actionable in code

Comments

@abobr
Copy link

abobr commented Jan 24, 2020

TypeScript Version: 3.7.2

Search Terms:
getter
property accessor

Expected behavior:
should return value from base class A, which for the example provided is 10

Actual behavior:
returns value from class B, which for the example provided is 200

Related Issues:
#36346
#29305

Code

class A {
    a = 10;
}

class B extends A {
    _a = 200;
    get a() {
        return this._a;
    }
    set a(v) { this._a = v; }
}


console.log(new B().a);
Output
"use strict";
class A {
    constructor() {
        this.a = 10;
    }
}
class B extends A {
    constructor() {
        super(...arguments);
        this._a = 200;
    }
    get a() {
        return this._a;
    }
    set a(v) { this._a = v; }
}
console.log(new B().a);
Compiler Options
{
  "compilerOptions": {
    "noImplicitAny": true,
    "strictNullChecks": true,
    "strictFunctionTypes": true,
    "strictPropertyInitialization": true,
    "strictBindCallApply": true,
    "noImplicitThis": true,
    "noImplicitReturns": true,
    "useDefineForClassFields": false,
    "alwaysStrict": true,
    "allowUnreachableCode": false,
    "allowUnusedLabels": false,
    "downlevelIteration": false,
    "noEmitHelpers": false,
    "noLib": false,
    "noStrictGenericChecks": false,
    "noUnusedLocals": false,
    "noUnusedParameters": false,
    "esModuleInterop": true,
    "preserveConstEnums": false,
    "removeComments": false,
    "skipLibCheck": false,
    "checkJs": false,
    "allowJs": false,
    "declaration": true,
    "experimentalDecorators": false,
    "emitDecoratorMetadata": false,
    "target": "ES2017",
    "module": "ESNext"
  }
}

Playground Link: Provided

@abobr
Copy link
Author

abobr commented Jan 24, 2020

in console the result is 10
Chrome Version 79.0.3945.130 (Official Build) (64-bit)

@jcalz
Copy link
Contributor

jcalz commented Jan 24, 2020

I'm pretty sure 200 is the correct output (why wouldn't a subclass use its own accessors when overriding a property in the base class?) and I can't reproduce your result of 10 using the same version of Chrome and the same emitted JS code:

Can you double check what you're doing and/or explain why you think the subclass should use the superclass's property value instead of its own?

edit: I get what's happening and am now sad

@nmain100
Copy link

The emitted JS code is an incorrect downlevel. If you take the typescript code (which is valid javascript, in this case) and paste it into the same console, you get 10.

If you want fully compliant behaviour you have to set useDefineForClassFields: Release Notes

@jcalz
Copy link
Contributor

jcalz commented Jan 24, 2020

Got it, thanks!

And blecch, that's unpleasant.

So the fix for this is to use the compiler option like this and this issue is essentially working as intended and possibly a duplicate of #27644

@RyanCavanaugh RyanCavanaugh added the Question An issue which isn't directly actionable in code label Jan 27, 2020
@RyanCavanaugh
Copy link
Member

This is one of the subtle differences between the "old" version of TypeScript class fields and what the committee ended up shipping. useDefineForClassFields will get you the "new" behavior to match e.g. Chrome's

@typescript-bot
Copy link
Collaborator

This issue has been marked as 'Question' and has seen no recent activity. It has been automatically closed for house-keeping purposes. If you're still waiting on a response, questions are usually better suited to stackoverflow.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Question An issue which isn't directly actionable in code
Projects
None yet
Development

No branches or pull requests

5 participants