On 30 May 2025 08:57:34 BST, Rob Landers <rob@bottled.codes> wrote:
>
>I’m starting to think that maybe modules might be a bad idea; or at least,
>class/module visibility.
>
>As an anecdote, I was looking to extract a protobuf encoding library from a
>larger codebase and create a separate library for Larry’s Serde library.
>During the extraction I realized that many of the classes and functions I was
>relying on actually used @internal classes/functions. If “module” visibility
>were a thing… would my implementation have been possible?
>
>In other words, if visibility comes with modules; there really needs to be
>some kind of escape hatch. Some way to say, “I know what I’m doing, so get out
>of my way.”
Isn't this exactly the same as any other "access control" feature?
We have private/protected methods and properties, final methods and classes,
readonly properties; other languages also have sealed classes, module and/or
file private, etc. All of these are ways for the author of the code to express
how they intend it to be used, and to protect users against *accidentally*
violating assumptions the code is relying on.
They are of course not *security* measures, as they can be bypassed via
Reflection or just editing the source code.
If you're using someone else's code in ways they didn't intend, that's up to
you, but you may need to make changes to do so, i.e. fork it rather than
relying on the distributed version.
In your example, the author clearly marked that those classes were internal
implementation details; if you use them directly and later update the library,
you risk your code breaking either completely or subtly. If you copy them into
your own codebase, you are free to remove the "@internal" annotations, or
future "module private" declarations, and make whatever other changes are
needed to suit your use case.
Regards,
Rowan Tommins
[IMSoP]
