In that case, they’ll be unable to access it from any other module anyway.
But I see your point. It certainly helps to keep the private specification closer together.
scarfacedeb
NobbZ
Perhaps we could make it an iex helper? That way we hide the implementation detail while also not exposing the function to everyone.
Having it an iex helper would even make name mangling possible again.
2
josevalim
Creator of Elixir
In my first proposal :visible_to was a required attribute but the proof of concept has evolved and made it optional. So I believe it can be made an attribute to. We can discuss this with more details in a later step when (or if) we pick one of those proposals.
Yup, that wouldn’t hurt either.
0
dimitarvp
Eh, you can modify the visible_to: [...] part anytime you wish.
IMO any new language features’ UX must be micro-optimized to hell for minimum possible mistakes when using them.
1
blatyo
Conduit Core Team
So, these solutions are primarily targeted at people who are using private APIs and are unaware that they are doing so. Is that common? If the predominant case is that people are using private APIs and they are aware, does this solve anything?
I don’t have a good gauge on that.
EDIT: I guess one benefit I can think of is explicitness over convention
0
dimitarvp
According to Jose in both threads so far, people are left with the impression that Elixir itself breaks backwards compatibility – when clearly people try to force their way in to quickly solving a problem and using an API that is intended to be private in the process. This is undesirable for marketing reasons and it doesn’t matter if people were doing things wrong if they step away from Elixir with the wrong impressions and never give it another chance. This is made worse if they advise friends and colleagues.
As for legitimate uses, I’d use this mechanism to communicate intent that certain modules are implementation details and that only their direct user modules – who provide better public API – must be able to access them. Having to deal with ugly and malformed external data (3rd party APIs give you those all the time) is a very good candidate for a private module. Ecto schema modules when dealing with a big and convoluted legacy database – another.
Introducing such a feature is a clear win in both cases: when people unwittingly break contracts, and when they want to introduce semantic boundaries in their projects.
5
bottlenecked
Since private modules are deemed a necessary addition, I think option D is the best compromise
- Warnings instead of hard errors
- The require+alias macro makes the feature perhaps more discoverable and more explicit than A
0
blatyo
Conduit Core Team
I guess I don’t see how any of these solve that problem. My guess is most people indirectly use private APIs indirectly via a library. So, when they upgrade Elixir and that library breaks, the assumption is Elixir broke it. If people are directly using private APIs and not realizing that they’re doing so, I could see what you’re saying being true.
0
josevalim
Creator of Elixir
It is a combination of everything said.
Many developers don’t think about boundaries because the language has no constructs to say so (besides @moduledoc false and @doc false, which are minimal). This means people don’t write annotations, which means that even if a developer would respect those boundaries, the boundaries are not there. And similarly, because those boundaries are not easy to check, you may accidentally cross them, even when they are defined.
For example, imagine you want to provide a reduce_with_super_power. You may do so by copying Enum.reduce source and then changing it a bit. The problem is that Enum.reduce called a private module, but you didn’t bother to check everything the code was calling when you copied that small snippet, and now your code may break in the next Elixir release.
This is just one example. Working on Ecto, Plug and Phoenix I saw it happening in other situations too. However, if someone knows that something is private and they decide to call it anyway, then there is nothing we can do. But at least they have been told so.
In general, it is about intent and communication and it is really hard to show intent and communicate when you have limited constructs to do so.
8
dwahyudi
I have some complicated formulas (ex: related to daily items average pricing calculation, weekly automatic discount placement, etc) in some modules that are only used by 1 or 2 modules. One These complicated formulas need to be splitted in different modules (for readability and testability), probably 3 to 5, one of them has 8 modules. Do I need to make them private?
Would hiding them be beneficial to my code? I haven’t tried it. But for sure, if I hide those modules, I only have to provide the public modules to be visible for other components to use. So this is much like the context principle in Phoenix? Access some functionalities only from its boundary? 
I kinda think that this private modules (if implemented) will push us to write smaller modules in the future.
Would this become confusion to my other components as well? Because I already have some public and private functions in some modules. But surely, this will change how I test my Elixir code if want to utilize private modules.
0