So when building a DSL, I often (following Ecto’s examples) will have an __attribute__/1 and similar functions that my DSL eventually calls into. Elixir does not generate documentation about these functions I’m wondering if there’s some parallel that can be made here, perhaps naming the modules defmodule __MyPrivateModule__ do ... end to convey similar intent. I’m not sure if we’re past that point already, but if it’s really just signalling to a user that something is private, that’s ugly enough to give a user pause, I think, and aligns with other conventions in the language, without requiring a new language concept, or requiring the private module to know its callers.
asummers
2
josevalim
Creator of Elixir
That’s a good question @asummers. Unfortunately __MyPrivateModule__ is not a valid alias name. Anything that starts with an underscore is either a function name or a variable. We could change the language to make __MyPrivateModule__ actually be an alias by checking the first letter after the underscores but that would not work with existing variables such as __MODULE__ and __ENV__. We would need to at least special case them in the parser (which is fine, they are already special cased in the compiler anyway).
The only downside of this approach is that it doesn’t say to which modules an underscored module would be visible to.
1
asummers
The only downside of this approach is that it doesn’t say to which modules an underscored module would be visible to.
@josevalim I think that’s okay personally. I don’t think this is something the compiler should need to enforce if the problem is largely social. If someone’s using an underscored module, that’s their fault. They know the risks when they decided to use that module name, same as if they called an underscored function name. Perhaps that isn’t strong enough but to me not closing the private module (a la open/closed type semantics) seems more optimal.
0
tmbb
I rather like having to use requirep insead od require + alias. It makes it explicit that we’re requiring a private module.
1
Eiji
In such case I would prefer to require using == when defining dependency version.
defmodule MyApp.Mixfile do
# …
def project do
[
# …
deps: [{:some_dep, "== 1.5.3"}], # fails if not using == version check
private_access_overrides: [ # By this not being empty then this project is not allowed onto hex.pm
some_dep: {SomeDep.Private, [MyApp.Some.Specific.Module, MyApp.Some.Other.Specific.Module]}
],
# …
]
end
# …
end
I like that idea, but note that in such case we would also need option like: package_namespaces: [MyApp, MyAppTest] and validate all defined modules inside lib and test. It’s because somebody could write defmodule SomeDep.Hack do … end. The problem with that is we can’t do it directly in compiler as @josevalim said. Doing it from some code analyse tools is also not a solution, because we could call something like: Code.require_file("hacks/some_dep/hack.ex").
0
OvermindDL1
The dependency resolver could use the information from the private access listing to try to acquire that specific version as well, but honestly I’d still prefer it to ignore it and for updates to ‘break’ it to encourage fixing it faster. It’s not like such a library that uses this construct would be allowed on hex.pm anyway.
Hmm, actually another idea, the private access overrides could go as options on the dependency tuple itself… Many places it could go.
And can’t forget that that could be entirely intentional, like say to expose a ‘private’ API only to a protocol’s implementations.
I’m not sure what an option would be for?
Though I don’t think the original C option to allow it to be an entire subtree match is right either, that should also be explicitly per-specific-module with an option for an entire subtree (great for protocols for example).
0
Eiji
Ah, sorry - I though that you are talking about extra protection (when reading that part with hex checks), so I just started talking about possible hacks. 
I did not realized that you wanted to only extend access for specific private modules. It’s good idea too. 
1
chrismccord
Creator of Phoenix
amatalai
It would be nice if requirep Foo.Bar could automatically alias :"Elixirp.Foo.Bar" to Foo.Bar (I’m aware that elixir doesn’t support nested aliases and it probably won’t happen).
Anyway, option C is something that would be useful for me even today.
2
tmbb
I also like the name mangling features. I suggest a deterministic naming scheme like the following: Elixirp.<hash_of_the_module_name>.Module.Name. That
I wonder if it would be possible to have a make_all_private_modules_public/0 function or macro on IEx, which would alias all private modules somehow.
0