On 30 May 2025 08:57:34 BST, Rob Landers <[email protected]> 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]