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

Definition overriding only takes first definition #27

Closed
bmalehorn opened this issue Aug 14, 2014 · 4 comments
Closed

Definition overriding only takes first definition #27

bmalehorn opened this issue Aug 14, 2014 · 4 comments

Comments

@bmalehorn
Copy link

For example,

declare class Foo {
  public y: {
    /**
     * foo
     * @returns The current y value.
     */
    (): number;
    /**
     * bar
     * @param value The desired y value.
     * @returns The calling Foo.
     */
    (value: number): Foo;
  }

  /**
   * baz
   * @returns The current z value.
   */
  public z(): number;
  /**
   * ack
   * @param value The desired z value.
   * @returns The calling Foo.
   */
  public z(value: number): Foo;
}

Will produce this:

screen shot 2014-08-14 at 4 33 20 pm

Notice that z's documentation is messed up. Only the first docstring is taken.

Really, y and z should have identical documentation.

@sebastian-lenz
Copy link
Member

Hi bmalehorn, nice to hear from you. Did you click on the second signature of z? It's actually an accordion and you can reveal the different overload definitions by selecting its signatures.

I don't know why you expect the reflection of y and z to be the same. y is an object literal while z is a function with multiple overloads.

@sebastian-lenz
Copy link
Member

Now I see it, the two call signatures of y should be placed in an accordion too.

@Evgenus
Copy link

Evgenus commented Aug 15, 2014

+1 for constructors in accordion

@bmalehorn
Copy link
Author

Did you click on the second signature of z?

Ah, I can't believe I didn't notice this earlier. I'm fine with this setup.

You can change y to accordion if you want, but I don't think it's necessary. If you change y to accordion, it would suddenly change to non-accordion as soon as you added a non-function signature.

You can close this issue if you want, or keep it open if you want to make y accordion.

@Gerrit0 Gerrit0 removed the bug Functionality does not match expectation label Feb 2, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants