Don't require to implement optional abstract properties
See original GitHub issueSearch Terms
abstract optional override
Suggestion
If in abstract class abstract property is marked as optional, allow child classes not to implement it.
So I suggest to remove an error for property x
of class D
in the following code:
abstract class A {
protected abstract readonly x?: number
protected abstract readonly y: number | undefined
public doSmth() {
console.log(this.x, this.y)
}
}
class D extends A {
protected readonly y = 10
}
new D().doSmth()
But property y
still must be implemented.
Note that we already can do some sort of it
interface I {
propertyCanSkip?: number
propertyMustImplement: number | undefined
methodCanSkip?(): void
methodMustImplement(): void
}
abstract class A {
propertyCanSkip?: number
abstract propertyMustImplement: number | undefined
abstract propertyMustImplementToo?: number
methodCanSkip?(): void
abstract methodMustImplement(): void
abstract methodMustImplementToo?(): void
}
class CA extends A {
/*
Non-abstract class 'CA' does not implement inherited abstract member 'methodMustImplement' from class 'A'.(2515)
Non-abstract class 'CA' does not implement inherited abstract member 'methodMustImplementToo' from class 'A'.(2515)
Non-abstract class 'CA' does not implement inherited abstract member 'propertyMustImplement' from class 'A'.(2515)
Non-abstract class 'CA' does not implement inherited abstract member 'propertyMustImplementToo' from class 'A'.(2515)
*/
}
class CI implements I {
/*
Class 'CI' incorrectly implements interface 'I'.
Type 'CI' is missing the following properties from type 'I': propertyMustImplement, methodMustImplement(2420)
*/
}
But there is a set of problems for properties
We have two ways to override property (via property declaration or via getter and setter). And now (in TS4) the limitation have changed. For nonabstract property base class always defines how it should be implemented in children.
Let’s look what implementations are possible (don’t forget about useDefineForClassFields
compiler flag that makes it more important):
Code | Property can be omitted | Child can implement as property | Child can implement as get/set |
---|---|---|---|
propertyCanSkip?: number |
Yes | Yes | No |
abstract propertyMustImplement: number | undefined |
No | Yes | Yes (except https://github.com/microsoft/TypeScript/issues/40632) |
abstract propertyMustImplementToo?: number |
No | Yes | Yes (except https://github.com/microsoft/TypeScript/issues/40632) |
get getter?(): number |
N/A | N/A | N/A |
abstract get getterMustImplement(): number | undefined |
No | No | Yes |
abstract getterToo?(): number |
N/A | N/A | N/A |
It’s easy to see, that if the property should really be optional, there is only one way to make it such which will not allow to implement it as getter and setter. But we have 2 absolutely identical lines with optional and nonoptional abstract property. I see no sense for them to be synonyms as ?
in the 3rd line definitely says that the property is optional, but doesn’t give me ability to make so in further code.
So I propose to change this table in following way:
Code | Property can be omitted | Child can implement as property | Child can implement as get/set |
---|---|---|---|
propertyCanSkip?: number |
Yes | Yes | No |
abstract propertyMustImplement: number | undefined |
No | Yes | Yes |
abstract propertyCanSkipToo?: number |
Yes | Yes | Yes |
get getter?(): number |
N/A | N/A | N/A |
abstract get getterMustImplement(): number | undefined |
No | No | Yes |
abstract get getterCanSkipToo?(): number |
Yes | No | Yes |
Abstract getter is NOT a part of this feature request, just shown for consistency.
Use Cases
Provide ability to list and use for reading an optional property in abstract class without limiting a way of its implementation in child classes. Such problem occured in a real project because of migration from TS3 to TS4. Before that it was possible, but because of breaking changes of TS4 it’s not anymore.
abstract class A {
protected readonly smth?: number
public f() {
console.log(this.smth)
}
}
class B extends A {
smth = 10
}
class C extends A {
get smth() { return Math.random() }
}
class D extends A {
}
new B().f()
new C().f()
new D().f()
Examples
See above.
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.
Why it’s not a breaking change?
It changes behavior of existing construction, but it’s not a breaking change in terms of code.
If you had your code working and you have
abstract propertyMustImplementToo?: number
in it, that means that you implemented this property in all child classes. So after its meaning changes all you code keeps being valid and compiles into absolutely the same javascript code as before. Nothing changed.
At the same time, for further development you have to decide whether you want to allow child classes to skip the property or not. If yes, or you don’t care - keep it with ?
as it is. If no then update it to
abstract propertyMustImplementToo: number | undefined
without any other changes needed.
Related Issues:
https://github.com/microsoft/TypeScript/issues/6413 https://github.com/microsoft/TypeScript/issues/22939
Issue Analytics
- State:
- Created 3 years ago
- Reactions:10
- Comments:13 (7 by maintainers)
Top GitHub Comments
I said
are checked the same today (and emitted, but that’s bug #40699)
This issue requests that
B
be valid code, and not required to beabstract
. But that’s the same asD
.I’m having something like the code below (simplified) in our project, which we’d like to run with :
The idea is that sub-classes must specify how the properties are defined (including if they are based on getters or values), and once they do that they can’t be changed, but the
optionalProperty
either is a string or it’s not present at all. Note thatexactOptionalPropertyTypes
makes the distinction between “a property is not present” and “a property has theundefined
value” explicit.In apparent contradiction with some of the comments above, it seems impossible to actually define a subclass of
BaseClass
whose instances don’t have theoptionalProperty
at all.(Well, I can define it by adding a constructor that explicitly
delete
s the property, but that’s not what I mean. TypeScript complains about deletingreadonly
properties, so I’d need to add some casts.)