-
Notifications
You must be signed in to change notification settings - Fork 12.8k
Support for optional abstract members in an abstract class body #22939
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
Comments
and why not just: abstract class Foo {
abstract foo(): void
bar?(): void;
} |
Because this means that |
but how would you witness that? you can not just call |
Automatically closing this issue for housekeeping purposes. The issue labels indicate that it is unactionable at the moment or has already been addressed. |
You may not need abstract at allI've hit this issue a few times, and one possible approach is to do this - without the abstract keyword.
One of the reasons you may think you want 'abstract' is to enforce the method signature. So that 'bark' will return the expected type in any subclass. If you convert the above code to C# it will compile, because it's allowed for the subclass to return a different type. And of course C# has virtual and override that typescript currently does not. However in typescript if the subclass doesn't return the same type then it just won't compile.
I had cases where I had an optional method in 10% of subclasses, but I wanted the signature to be enforced by the base class if it did exist. The above allows me to do that without any extra keywords. The only thing that may not be desirable is that the base class method returns undefined - but for me that was just fine. Also even without 'abstract' you can rename the baseclass method and (at least in VSCode) it will rename all the subclass methods too :-) |
TypeScript Version: 2.8.0-insiders.20180320 (version currently running in playground)
Search Terms:
abstract optional
Code
Expected behavior:
It should be possible to omit the definition of
bar
in theBar
class.If something constructs an instance of
Bar
, it should not be possible to callnew Bar().bar()
, either because it is consideredundefined
or because it still retains some "abstractedness".The intent is to use this in type definitions where subclasses can optionally define methods that will be called by their superclass; similar to lifecycle events in
React.Component
.Not making them abstract allows things such as calling
super.componentDidMount()
even though it does not exist inReact.Component
's prototype, or having a subclass without their ownrender()
implementation because TypeScript thinks it is provided byReact.Component
.Supporting optional abstract members could also be used to guard against the common error of not initializing
state
on classes that usethis.state
-- it does not actually exist until either the firstsetState
call or untilthis.state
is assigned, and initializingthis.state
by assignment is far more common than initializing it withsetState
.Actual behavior:
It's not possible to omit it unless
bar = undefined
is specifically added toBar
Playground Link: Playground Link
The text was updated successfully, but these errors were encountered: