-
Notifications
You must be signed in to change notification settings - Fork 1.1k
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
Comments
(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) |
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 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 |
I think that currently Scaladoc groups members pretty much like described in this task. |
Not completely:
This is not solved. Also there is a category called "Classlikes" but this term is not standard Scala jargon. |
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
The text was updated successfully, but these errors were encountered: