I agree with @JEG2 sentiment too.
Some kind of warning will help to define the public interface and its borders. But making it too strict does more harm than good.
I can think of at least 2 uses of open private modules:
-
As @JEG2 said, sometimes you have to use private modules in IEx in prod.
You may encounter an unexpected error that you didn’t anticipate in your code and the quickest way to debug it is to call internal modules by hand and check the results.
You could also use tracing in these cases, but I don’t see why we can’t have both. -
When I’m learning how a new library (or app) works, I often call its internal modules directly to experiment and get a better idea how they work under the hood. Now it’s easy to do in iex and it doesn’t require to now about any new concepts (such as private modules, their visibility, etc).
I think that a warning is the best of both worlds.
It’ll inform the unaware users that they shouldn’t use the module directly, but allow to debug it in the critical circumstances.
