-
-
Notifications
You must be signed in to change notification settings - Fork 710
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
✨ Introduce an @internal
attribute for individual declarations.
#2486
Comments
Seems reasonable to me. We will see if anyone has any thoughts or adjustments or objections. It should also be excluded from autocompletions from other packages. |
@internal
@internal
attribute for individual declarations.
Makes sense to me. Gonna keep my eye on this issue and start working on it when it's final. |
I could use this too, I like the current |
Won't this be a little bit confusing? First, because it seems somewhat symmetric to Looking at Rust for alternative ideas, there are two things that I understand would satisfy the current proposal's goals: there's the Couldn't we go one of these ways? |
@cauebs brings up a very good point. It can't be |
We already have a notion of # Modules that should be considered "internal" and will not be included in
# generated documentation. Note this currently only affects documentation;
# public types and functions defined in these modules are still public.
#
# Items in this list are "globs" that are matched against module names. See:
# https://docs.rs/glob/latest/glob/struct.Pattern.html
#
# The default value is as below, with the `name` of your project substituted in
# place of "my_app".
internal_modules = [
"my_app/internal",
"my_app/internal/*",
] Having public functions that aren't visible is useful for FFI and Testing. Having an |
I know, but when it's a config in |
It hasn't come up yet with internal modules, but I can see what you mean. We could rename them both to something else if we have a better name. In OOP this is sometimes called
Aye, that's the goal of the feature. It's a statement about the contract between the user and this program.
They would be, aye. |
@hidden
pub type HiddenThing |
I'm not a huge fan of hidden as I think that name describes a consequence of what they are, but not what they are. The contract of them being externally private is far more important than them being hidden from documentation. |
|
Perhaps |
I don't think it accurately describes what it does. The advantage with my three suggestions is that anyone seeing them for the first time, without any explanation, could arrive at some vague conclusion of what they do! |
You say that, but I don't know what any of those three words mean in this context. They're not restricted or reserved in any way, and I'm not sure what they're exclusive of. I find |
I don't agree that
|
my bad! Although I still don't see |
Remember that the purpose of this annotation is to hide a declaration from the generated docs. That means anyone who sees this annotation is necessarily looking at the source code! That means they are beyond the realms of a normal package consumer, and are now someone,, looking at the internals! From that perspective, it becomes immediately valuable to see a I think I've convinced myself further that Unrelatedly, to add more support to this issue in general. It would be nice to be able to mark the |
This is the same for The programmer wrote this code, they are making statements about it to other people rather than themselves. |
we have in this respect, i could put my i may not be grokking the proposal perfectly, but I prefer something like the rust strategy over 🤔 |
I agree with Hayleigh and Also to add to the issue, we would need to warn if any type marked as @internal is inadvertently exposed in the public api (just like suggested here #2234) |
@cdaringe This is similar but not the same as making an item public or private for a package or set of modules. I would also be interested in a system for drawing lines within a package to enforce certain relationships between subsystems, but we don't have a good design yet. Rust's system is capable but I've never seen anyone do more than If we determine a good design for this it can be added in future. Both this internal system and a more powerful public/private system have their own uses. |
I think this can be closed now 🥳 |
Thank you!! |
Background
Currently we have the
internal_modules
entry in ourgleam.toml
as a way of excluding certain modules from the generated documentation. Anypub
code is always importable, but by excluding it from the docs it is de facto internal and not part of the public API.This solution works well when you have large chunks of internal functionality, but quickly gets clunky when you have small bits of internal functionality next to public code.
It is good practice to define custom types as
pub opaque
unless there is good reason to do otherwise: this means consumers can't pattern match on your custom types and the implementation details remain hidden. Because of this though, it is not possible to have apub opaque
type part of the public API and a separate internal module that can pattern match on that type.Propsal
I'm proposing an
@internal
attribute that can be attached to declarations that hides that declaration from the generated documentation in an otherwise-public module:Here this
encode
function needs access to the structure of theWibble
type in order to encode it to JSON properly, but the function itself is not part of the public API. This is handy if we have other parts of a package that might need to know how to encode a Wibble.Prior art
Elixir has this functionality by setting
@doc false
, see hereThe text was updated successfully, but these errors were encountered: