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

Adding a compilerOption to disable error on property override accessor in 4.0.beta #39401

Open
4 of 5 tasks
xuld opened this issue Jul 3, 2020 · 6 comments
Open
4 of 5 tasks
Labels
Awaiting More Feedback This means we'd like to hear from more people who would be helped by this feature Suggestion An idea for TypeScript

Comments

@xuld
Copy link

xuld commented Jul 3, 2020

Search Terms

property override accessor

Suggestion

Previously in 3.9, property can override an accessor with no emit errors. And in 4.0 beta, a break change was introduced by #33509.

It's reasonable to report an error on property override accessor in most case, but I'm using experimentalDecorators to inject a property accessor in prototype.

Currently I cannot find a solution for this use case, so I'm suggesting to add a new compilerOption to disable this check(strictOnly?) for compatibility.

Use Cases

class Animal {
    private _age: number
    get age(){ return this._age }
    set age(value){ this._age = value }
}

class Dog extends Animal {
    @defaultValue(100) age: number;     // Unexpected error here
}

function defaultValue(value) {
    return (obj, name) => {
        Object.defineProperty(obj, name, {
            get() { return value }
        })
    }
}

Checklist

My suggestion meets these guidelines:

  • This wouldn't be a breaking change in existing TypeScript/JavaScript code
  • This wouldn't change the runtime behavior of existing JavaScript code
  • This could be implemented without emitting different JS based on the types of the expressions
  • This isn't a runtime feature (e.g. library functionality, non-ECMAScript syntax with JavaScript output, etc.)
  • This feature would agree with the rest of TypeScript's Design Goals.
@RyanCavanaugh RyanCavanaugh added Awaiting More Feedback This means we'd like to hear from more people who would be helped by this feature Suggestion An idea for TypeScript labels Jul 14, 2020
@whzx5byb
Copy link

I agree. Some old version .d.ts files for 3rd-party library may contain unprecise definitions, such as declaring accessors as properties, for example, PIXI.js v4.x:

class Sprite extends Container {
...
  width: number; // <- in fact accessor here
  height: number; // <- in fact accessor here
...
}

So extending this class will cause an error:

class MySprite extends PIXI.Sprite {
  /** @override */
  get width(): number {
    // 'width' is defined as a property in class 'Sprite', but is overridden here in 'MySprite' as an accessor.
  }
}

Since changing all these legacy definition files is a lot of works, a compiler option will be of much help.

@miltoncandelero
Copy link

Any updates on this? Or how to circle around the pixijs error? 🤔

@Yazir
Copy link

Yazir commented Aug 24, 2021

Having the exact issue here. Stuck below 4.x with no option to update without major overhauls.

@Mahi
Copy link

Mahi commented Aug 12, 2022

When designing a class, it is impossible for one to know who will extend their class in 10 years and for what reason. Just because you can't think of a reason to extend some functionality today doesn't mean it won't be needed in the unforeseeable future by someone else. This is why in C++ it's good practice to make your attributes private and write getAttr() and setAttr() methods for every single attribute, even if they don't do anything; so that others can override them in the future if they need to. Also so that you yourself can change the implementation without breaking backwards compatibility in the future.

Languages like Python and C# tackle this issue with get and set; you can make all your attributes public, and change the implementation in the future without changing the public interface. Others can override your attributes with custom behaviour in their subclasses. TypeScript completely prevents us from doing this, and forces us back to the C++ hell of writing getters and setter for every attribute even if we don't need to; just in case we might in the future.

@EthanRutherford
Copy link

I would argue this shouldn't even be considered an error in the first place, the whole point of an accessor is that it's supposed to be indistinguishable from a regular property to external consumers.

@adamk33n3r
Copy link

Just ran into this issue, I'm also using a library that defines a property and I would like to override it with an accessor but I cannot.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Awaiting More Feedback This means we'd like to hear from more people who would be helped by this feature Suggestion An idea for TypeScript
Projects
None yet
Development

No branches or pull requests

8 participants