Will do.
dwahyudi
dimitarvp
I don’t disagree. But it still requires you to do something special in order to circumvent the private nature of the module anyhow; only it will be a well-known mechanism in the stdlib API and it will have better readability.
50/50 though, would not insist on it. Plus adding stuff to the stdlib is a really heavy-handed measure, that much is true.
1
imetallica
About point A:
I’m not sure if this is a good idea at all but, what if instead of being an exposed module, we inline all the functions/macros/etc… of the private module, inside the modules listed in @visible_to: [Foo, Bar, Baz]? Is that possible? Also, how could we guarantee that the use X from the private module doesn’t conflict with the use Y that uses the private module?
0
dwahyudi
It’s just some libraries in our app, not a standalone app. Each module has its own test file. Just functions grouped by modules, nothing really fancy. But because they contain some arcane formulas, readability and testing is really necessary here for each module. We just couldn’t test only the top calling function and expect some magic to work.
Anyway, I also work in Ruby on Rails code in my fulltime job, having service pattern (something like this: https://hackernoon.com/service-objects-in-ruby-on-rails-and-you-79ca8a1c946e) and form classes really helps me and my team to do testing and splitting the code for maintainability, it has been a breeze. But these service and forms classes are public, and they are reusable for anyone. (But this pattern also raises some significant problems that I will explain below.)
What comes to my mind, is that Elixir private module is a sort of contract for code reuse in internal app/library, but not for global/public. “You want to use this? Well just whitelist/make visible the caller.” This is probably intended for several people working together in a close ‘vicinity’. Probably the one who create a private module will be the one who will call (whitelisting) it as well. Something like: Jose created a private module, the farthest people who is going to call it is probably Chris McCord, not me, not you, not most Elixir users. CMIIW.
I’m kinda thinking that Elixir private module (if it is implemented) is best used for hiding inner complexity for libraries. “Yes you can test it, but please don’t call it if you can. Let us handle and maintain this private module. You don’t need to. You don’t have to.” This is in contrast with above service pattern, where everyone can use it, and hence when somebody needs to change (or hack it 
) it, it will affect all other codes which call it, it will end up with many flag variables if we don’t immediately refactor/duplicate it.
Now after some moment of thinkings, this private module proposal made me (and my friend) to rethink “among 18 modules that we got here, which one should go public for other developers to reuse? Should they be reusable? 
”. This in turn raise a question to me, which module should go public and reusable, which module should be private.
0
JEG2
Author of Designing Elixir Systems with OTP
knewter
Option C for sure, for the ergonomic and pragmatic reasons described earlier. I like the addition of the feature generally as well.
1
devonestes
I vote Option C.
Just to be super clear, this would be a compile time error, right? For example, will the following code compile?
defmodule MyApp.Other do
alias MyApp.Private
Private.hello()
end
Also, will private modules be able to be imported?
defmodule MyApp.Other do
require MyApp.Private, as: Private
import Private
hello()
end
And what about useing a private module?
0
josevalim
Creator of Elixir
dimitarvp
That’s exactly the productive thoughts such language features are supposed to provoke!
It’s OK to have a lot of internal modules that deal with various aspects of something big and ugly. They usually have to be private – and this proposal will still allow you to test them. But they usually shouldn’t be exposed as a public API inside your project.
0
OvermindDL1
OCaml does it via mli files, which are like h/hpp files in C/C++, they define an interface to a given module, and they can be different between internal use and external distribution (though that’s not a common pattern).
C++ namespaces can be hidden, that’s what an unnamed namespace is:
namespace MyApp {
namespace {
// Private functions here, entirely not accessible outside of this file and this file only
}
// Public functions here
}
You can’t even ‘craft’ a function pointer to such a function (not unless it’s returned via some other method).
You can ‘expose’ methods only to specific other (static) classes using friend, which lets you have ‘scoped’ static functions or methods that can only be called be specifically marked other classes, though this is not a common pattern either.
And of course C/C++ has headers as well, of which some can be internal and not exported to users of the library, that means you can even have multiple headers for the same ‘implementation’ with different things exposed in them, however the user of the library can ‘expose’ them manually by explicitly declaring them (which is definitely a red flag).
I’m personally for C, a hard error should be raised for invalid private access along ‘normal access patterns’, however there absolutely must be a way to bypass it as well for both live debugging purposes and working around issues in dependent libraries, and I wouldn’t want that via a :"elixirp.Blah".call() (though that would be nice for iex use, but its awful easy to abuse), thus I’d propose C with a slight extension being that in the mix.exs file a new attribute can be given to give a specific list of private modules to public module mapping overrides for the current project. Perhaps even hex.pm could disallow hosting of libraries that use any of such mappings. Perhaps it could look like:
def project do
[
...
private_access_overrides: [ # By this not being empty then this project is not allowed onto hex.pm
{SomeDep.Private, [MyApp.Some.Specific.Module, MyApp.Some.Other.Specific.Module]}
],
]
end
Maybe the tuple should even encode the SomeDep’s version number somehow as well, so it must be changed (or removed and properly fixed) each time it is updated.
EDIT: And iex access should be allowed via require SomeDep.Private, as: Private from within iex unbounded (with a warning printed each time it is used from within IEx too, just to make it obvious).
3