Proposal: Private modules (general discussion)

[josevalim]

@imetallica

@josevalim although already said that elixir and the compiler doesn’t have the concept of “applications”, I think the way forward would be “internal” modules that are only accessible on the current “application”/“library”, since this would:

1. allow testing, since tests are inside the “application”.
2. hide the implementation from outsiders.

Which is precisely what we want to do here. I think this should be reconsidered.

I have been thinking about this approach and I even had a proof of concept and it is really inferior to the alias approach mentioned in B/C/D. For example, imagine this macro in your library:

require SomethingPrivate.Helper, as: Helper

defmacro does_something(arg) do
  quote do
    Helper.compute_x(unquote(arg))
  end
end

If it is per project, Helper is now being used in a third party application due to meta-programming and therefore it will not work. With the require+alias system however, once you alias a private module and you have permission to use, you can pass it around and it will always work. In other words, it works more like an ownership system, which is really neat and transparent.

Perhaps, however, the worst about doing the visibility per project is that if you mess it up, like in the example above, you will only find it out when somebody else uses your project. Probably after a new version is released, and that is quite worse than any of the other proposals mentioned here, which requires you to always consider the visibility.

Finally, you have to remember that IEx is its own application and the application you are working on is lost once you build a release and connect to a remote node, which means that this approach would also make it impossible to debug your private modules in a live system.

So besides the compiler not really knowing about applications, you can see that doing something per project is more error prone than the current proposals in many ways.