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

SUBTYPES abbreviation #47

Open
tpapp opened this issue Dec 1, 2017 · 3 comments
Open

SUBTYPES abbreviation #47

tpapp opened this issue Dec 1, 2017 · 3 comments

Comments

@tpapp
Copy link
Contributor

tpapp commented Dec 1, 2017

It may be useful to add a SUBTYPES abbreviation that expands to something like

subtypes: [`SubType1`](@ref), [`SubType2`](@ref), ...
@tpapp
Copy link
Contributor Author

tpapp commented Aug 27, 2018

Revisiting this issue, I am wondering about the utility of this abbreviation, as subtypes of a type is an essentially dynamic value that may change when new code is evaluated (eg a package is loaded). Eg if it ends up in statically generated documentation (by Documenter.jl) it can easily be inaccurate.

Thoughts? I am thinking of just closing this issue.

@mortenpi
Copy link
Member

That's a fair point. Maybe it should filter by module somehow?

@MichaelHatherly
Copy link
Member

Maybe it should filter by module somehow?

That does seem like a reasonable approach, e.g. the printed out types are all subtypes of the documented type that are defined within the type's defining module or any of it's submodules and any external modules that further subtype it are not included. We could print out something to that effect as an admonition in the expanded abbreviation to warn readers.

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

3 participants