Skip to content

API doc: don't separate vals, defs, and objects in different categories #10893

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

Open
smarter opened this issue Dec 23, 2020 · 4 comments
Open

Comments

@smarter
Copy link
Member

smarter commented Dec 23, 2020

Currently, API pages split value members in two categories "Methods" and "Fields", and objects go into the "Type members" categories (even though they're not types), but from the point of view of a user these distinctions do not matter: the way they call and use something does not change based on whether it's an object, val or def, so I suggest grouping all these things as "value members", like Scala 2 does: compare https://www.scala-lang.org/api/current/scala/collection/immutable/TreeSeqMap$.html with http://dotty.epfl.ch/api/scala/collection/immutable/TreeSeqMap$.html

@smarter
Copy link
Member Author

smarter commented Dec 23, 2020

(on the other hand, I think splitting implicit/givens in their own category makes sense since they're used in a different way, I'm not completely sure about whether we should split inherited vs non-inherited (javadoc does it but scaladoc doesn't), but I think that's less important)

@abgruszecki
Copy link
Contributor

I also think that the way that Scaladoc grouped together vals, defs and objects makes sense. It's already there in the new docs. We seem to have a problem though, objects are displayed as vals and their pages can only be accessed by clicking on their type: http://dotty.epfl.ch/api/scala/collection/immutable.html#StringOps

Reg. grouping inherited definitions separately, I think it makes more sense to keep them together by default. The docs of List show that well - most definitions are in a separate group, which doesn't really help with reading them : http://dotty.epfl.ch/api/scala/collection/immutable/List.html . We had plans to allow for dynamic grouping, so perhaps having a toggle that moves inherited definitions to their own group would be good?

/cc @romanowski

@pikinier20
Copy link
Contributor

I think that currently Scaladoc groups members pretty much like described in this task.

@smarter
Copy link
Member Author

smarter commented Jan 10, 2022

Not completely:

objects go into the "Type members" categories (even though they're not types)

This is not solved.

Also there is a category called "Classlikes" but this term is not standard Scala jargon.

@smarter smarter reopened this Jan 10, 2022
@ckipp01 ckipp01 removed the discussion label Jun 6, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants