Skip to content

Constructor type being linked to property #2007

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
Levi-Lesches opened this issue Aug 21, 2019 · 8 comments
Closed

Constructor type being linked to property #2007

Levi-Lesches opened this issue Aug 21, 2019 · 8 comments

Comments

@Levi-Lesches
Copy link

Consider the following:

class Temp {
  final int temp;
  
  Temp (this.temp);
}

In the docs for this class, clicking on the Temp of the constructor links to temp the property. Is there any way to get around this?

@Levi-Lesches
Copy link
Author

Also, searching it gives "Temp (constructor)" but clicking on the search result gives temp the property.

@keertip
Copy link
Collaborator

keertip commented Sep 4, 2019

Which OS are you running on? This is likely due to the fact that the file system is not case sensitive and so the documentation for Temp constructor is overwritten by doc for temp property, the file names being the same expect for T vs 't'. Try renaming temp and see if this is still an issue.

@Levi-Lesches
Copy link
Author

Levi-Lesches commented Sep 4, 2019

Ah that makes sense. And yeah, in my many other classes this issue is not present (except for #2008, but I doubt this is related). But even if my host OS supported a case-sensitive file system, wouldn't anyone who downloaded it have problems viewing it? How can this be avoided in general? Can dartdoc change the filenames like Temp-constructor.html and temp-property.html? IMO it seems kind of restrictive to not be able to document a class like this.

@keertip
Copy link
Collaborator

keertip commented Sep 5, 2019

There was a similar bug where we changed the file names #585. Currently html files for class and constants are qualified, we could extend it for property too.

@Levi-Lesches
Copy link
Author

And if #1983 is being worked on, maybe this whole thing can be avoided? The general goal of it seems to be to no longer need a separate file for every member of a class, so that should help.

@keertip
Copy link
Collaborator

keertip commented Sep 16, 2019

Yes, #1983 would address this issue, but there is no eta on when it will be worked on.

@Levi-Lesches
Copy link
Author

So what should be done in the meantime? Should I just rename properties going forward to avoid this?

@jcollins-g
Copy link
Contributor

This is a direct duplicate of #1196 though as @keertip mentions #1983 would likely fix this as well.

Renaming properties or using a case-sensitive filesystem are the only workarounds we have at the moment.

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

3 participants