Does anybody have an example of private modules in other languages? Especially functional ones.
Maybe we could learn from them.
scarfacedeb
josevalim
Creator of Elixir
Yup! I am interested in exploring the impact this feature may have in the language in terms of code organization and documentation. As @imetallica said, defmodulep really isn’t a good name, so maybe we can find a name that is more intention revealing and will guide us in the matters of code organization.
0
dwahyudi
One of my friend said he has 18 modules that have only one top function to call in order to call 18 of them all. It was a huge giant module that was later refactored into 18 (soon to be 20) small modules. He said that each of those 18 modules have its own test file and live inside our CI/CD pipeline.
We still don’t know if those 18 modules should be put under private (if module private is going to be implemented), and we still have no idea on how to test them once they gone private.
0
josevalim
Creator of Elixir
If you are willing to experiment, you can give it a try now using the POC from the previous discussion: GitHub - josevalim/defmodulep: API for defining and requiring private modules. · GitHub
The README also talks about testing but it should be mostly transparent. You can also bypass visibility for testing by using the qualified name. It is all in the README. Please do report your findings!
3
NobbZ
I can not tell about much, but the last time I checked the issue in haskell (which has proper namespaced modules), it was common to have an INTERNAL-namespace directly beneath the main namespace of the library.
There was only this convention, but much more obvious and discoverable than to have @moduledoc false. Especially when reading foreign code its more obvious that a certain piece is meant to be private.
I have no clue how it is done in other functional languages.
Another system I’m aware of, not in a functional language though, is gos. There you name a package internal (IIRC) and all its childs will only be accessible by childs of its parent. Due to the way how gos packages are namespaced (the source repository is part of the name) you can’t even mimick to be in that package. (Well, one could with abusing dependency vendoring, and then you’ll know when you update anyway).
In Java and C++ namespaces/packages can not be hidden, only their content. And its easy to open up even foreign namespaces and “impersonate” to get access.
So to be honest, I have not yet seen a system that realy makes privte stuff private, but I’d prefer an explicit “I am privat, you shall not use me” over a “I’m having no documentation, so please pretend you haven’t seen me”.
3
mischov
One thing that is conspicuously lacking from this entire thread is any discussion of how private modules might be tested.
As @dimitarvp alluded to, there is often a reflex to say “don’t test implementation details”, but when decomposing complicated functionality among several smaller private functions I’ve often regretted not being able to test them. I can easily imagine that I’d want to test the code in a private module as much if not more.
How would testing relate to the four proposals?
Edit: Or at least conspicuously lacking until the last few minutes while I was writing this! Still, I would like to know how testing would work in each of the four proposals.
3
NobbZ
You still can test them when they are private, just make sure that your tests have the correct alias-prefix.
Also similar to the proposed iex helper, some ex_unit helper would be thinkable as well, but I’m not sure if that is really necessary.
Last but not least, is this a library or a standalone application? If its the latter, hiding the modules might not be necessary at all. If it is a library though, I’d hide the modules by either @moduledoc false or the proposed defmodulep.
0
dimitarvp
I think this can very quickly turn into a game of whack-a-mole. First iex, then ex_unit, then who knows what else In-The-Future®.
Wouldn’t having a function like Module.get_private/1 that knows exactly how to find and return the private module be a better option?
1
NobbZ
I do not think so. But perhaps a :"Elixirp.Module.Private".get_private/1 which is declared in a way that iex and ex_unit only need to prepare wrappers? Then it won’t get out of sync if mangling or other details change.
If we expose that function directly, nothing (or not much at least) would change from where we are now, as it is still to easy to circumvent.
But of course, in ex_unit it should be never necessary, as you can easily create the test-module in a namespace that has access to the hidden/private module.
1
yurko
I think it would be a very welcome feature, currently it’s about discipline in any bigger app, so I’m excited about this proposal.
I like option B the most but would also be pretty happy with C.
0