Skip to content

Overriding methods has no way to inherit the parameter documentation from the superclass #24259

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

Closed
4 tasks done
ChiriVulpes opened this issue May 18, 2018 · 8 comments
Closed
4 tasks done
Labels
Needs Proposal This issue needs a plan that clarifies the finer details of how it could be implemented. Suggestion An idea for TypeScript

Comments

@ChiriVulpes
Copy link
Contributor

ChiriVulpes commented May 18, 2018

Search Terms

override param parameters doc documentation function method extends

The Problem

class CoolClass {
	/**
	 * I'm some neat and cool JSDoc info about `method`!
	 * @param arg I'm some information about an argument
	 */
	method (arg: any) {}
}

class NotAsCoolClass extends CoolClass {
	method (arg: any) {}
}

In this code example, method gets the following documentation:

I'm some neat and cool JSDoc info about `method`!

It does not get @param documentation (or any other @ documentation parameters). However, this would be very, very helpful to have. The main use case I have for it is for a modding API for my project. The way we currently handle it is we have an interface containing all our "hook" methods, and then a "Mod" class that implements that interface. All the hook methods on it are called by our code internally.

A modder can extend the Mod class to hook into the base code. The works great for us, however, this means that the documentation we have on the hook methods is only the method description and nothing about the parameters of the hooks (which is pertinent information).

Suggestion

Keep the @param information on methods without other documentation

I assume the main reason the information isn't currently kept is because subclass methods can do different things with the parameters. However, throwing them out all the time is a bit of an extreme solution. I suggest that if the subclass doesn't provide it's own documentation, it should keep all documentation from the superclass method. I think that 100% of the time it would be more useful for it to work this way.

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. new expression-level syntax)
@mhegazy mhegazy added the Suggestion An idea for TypeScript label May 23, 2018
@weswigham weswigham added Needs Proposal This issue needs a plan that clarifies the finer details of how it could be implemented. In Discussion Not yet reached consensus labels Nov 6, 2018
@RyanCavanaugh RyanCavanaugh removed In Discussion Not yet reached consensus labels Mar 7, 2019
@ChiriVulpes
Copy link
Contributor Author

Not quite a duplicate of #23215, but very closely related. (#23215 deals explicitly with static members)

@jespertheend
Copy link
Contributor

This is similar to #31267 I think. It has a PR but seems to have been abandoned.

@htho
Copy link

htho commented Jul 28, 2022

As far as I can see this is resolved at least since v4.2.3:

class CoolClass {
	/**
	 * I'm some neat and cool JSDoc info about `method`!
	 * @param arg I'm some information about an argument
	 */
	method (arg: any) {}
}

class NotAsCoolClass extends CoolClass {
	method (arg: any) {}
}

const x = new NotAsCoolClass();
x.method // also has parameter documentation

https://www.typescriptlang.org/play?ts=4.2.3#code/MYGwhgzhAEDCD28S3FaBvAsAKAJAHoAqQnXaQ6ASQHIBbaCeWgU2gDtmwAXaMNgE2jBEIaACkAygBF4waAEs2AM3i8ARvACuPAAYsuAC3j8dAQlLloAAQAOYAE5h6DgOZU6DJq0Ur7tbvLwbOpaPHy89i6aLGxcFoT4pPpGggAUrgBcvGwAngCUGAC+OMXYOKCQMABy8FwAghAISCiV0MwAHlzMAjBNyKgwWHjJxtDpkVl8+UUlOOVBEDzt0AC87MwA7tA19Y0iLVCpeQDcOO0AdCP8QA

@samschurter
Copy link

It may be semi-resolved, but the overriding method still does not get the type of the param from the parent in the signature.
image

It has also not inherited the type for type hints on the variable in the method body:
image

@htho
Copy link

htho commented Aug 25, 2022

It may be semi-resolved, but the overriding method still does not get the type of the param from the parent in the signature.

So you'd like to be able to override methods and not add types to parameters because the types could be inherited from the parent class?

Interesting point. The information is redundant, therefore it could be done.

On the other hand: If I change a type in a parent class, errors would pop up not in the signature (incompatible signatures) but in the implementation. This would make it much harder to actually find the reason for the problem.
Worst-case is, there is no error at all, because the implementation just happens to use the parameter in a way that is compatible with the new type. But the behavior changes without the developer noticing.

BUT: This is not the topic of this Issue.

IMO this one can be closed.

@ChiriVulpes
Copy link
Contributor Author

As stated above, this was actually resolved at some point without this issue being closed.

@viktor-podzigun
Copy link

viktor-podzigun commented Apr 21, 2024

For me it still doesn't show up in VSCode, found a solution though:

class Parent {
  /**
   * @param {string} a ...
   * @param {number} b ...
   */
  method(a, b) {
    // ...
  }
}

class Child extends Parent {
  /** @inheritdoc @type {Parent['method']} */
  method(a, b) {
    super.method(a, b);
    // ... do extra stuff ...
  }
}

Which will help VScode infer the types.

@rwalle
Copy link

rwalle commented Sep 3, 2024

It seems it still does not work properly in VSCode with TypeScript 5.5.

/** @type {Parent['method']} */ works but looks very confusing. I think developer should not need to do anything to get the signature inherited, unless there is a case I am missing.

#31267 was closed last week without any explanation.

I am planning to open a new issue -- any thoughts?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Needs Proposal This issue needs a plan that clarifies the finer details of how it could be implemented. Suggestion An idea for TypeScript
Projects
None yet
Development

No branches or pull requests

9 participants