Given it is defmacrop and not defpmacro, I think it should be defmodulep, even if for consistency. Also, having the p at the end makes it more visible than in the middle of the word.
josevalim
Creator of Elixir
hubertlepicki
Fair enough, I don’t think I’ve ever used defmacrop and didn’t know it existed. It should have been the other way around for easy remembering I think, i.e. code that reads like English comes in a bit more natural than arbitrary reversed. Smalltalk did that a lot, Objective-C as well and I always liked it. but anyway, thanks for clarification and I can very much live with that.
massimo
Why not the other way around?
declare the module private with an attribute (@private should be enough) and then to use it in your modules add a requirep keyword.
If you don’t requirep compilation fails.
The intent is clear and there cannot be confusion about using a private implementation that could break over time.
Eventually an optional @visible_to attribute could be used to restrict the “requirability” of the module.
josevalim
Creator of Elixir
Hi everyone,
Here are two concerns about proposals B/C/D. Since the require+alias are necessary, it may make the code too verbose. For example, imagine you have a Phoenix context with this:
alias MyApp.Blog.{Post, Like, Comment}
If we make those modules private, we need to break them individually as:
require MyApp.Blog.Post, as: Post
require MyApp.Blog.Like, as: Like
require MyApp.Blog.Comment, as: Comment
Which is considerably more verbose.
The other concern is that invoking require (or use or import) on a module defined in the same project, the current module will stop compiling until the required module becomes available and then it resumes compilation. This implies two things:
-
It is not possible to have circular dependencies between private modules. Although circular dependencies are arguably a consequence of poor design, it still is a difference in behaviour;
-
And there is a chance that if you require too many modules, compilation may slow down, as we need to wait for the require modules to finish compilation;
Those issues can all happen today but they are not very common because we don’t rely on require and similar between modules in the same project that often. However, adding private modules may be enough to make those issues more common and apparent.
This is not enough to block proposals B/C/D but it adds extra concerns to the mentioned proposals.
Note that one possible solution to this problem is to introduce requirep or aliasp. But we are concerned that adding yet another modified (besides alias, import, require, and use) will add more confusion and complexity than help.
qwerescape
I feel A, C, D are a little inconsistent to the current “private” behaviours, ie: defmacrop, defp. The current behaviours of defmacrop and defp are such that “they are only accessible in the module that they are defined in”. But the message that A, C, D send is: “it is discouraged to use this, but you can still use it if you want”.
B is the most consistent, perhaps it is the least useful? But I’d argue we’d have the same benefits if we made defp also “discouraged but allowed”.
Would it be worthwhile to explore a path where private functions are accessible with a special syntax? If that could be done, one can write a private module by making all its functions private…
mischov
You are correct. Technically I think it’s it’s semantics, not syntax, but does getting the word wrong really invalidate the point that you’re adding more overhead to a very central part of the language - defining a new module - which will also not be backwards compatible, and that such a choice has negatives inherent to it that should come into judgement on whether it’s a good idea?
I’m not suggesting it’s not worth it to do so, only that it should be a consideration when comparing solutions.
I now see the distinction you’re trying to make (though I’m not sure it’s obvious from your initial talk about being able to access to allow debugging of live systems), but is it a distinction captured in the behavior of the code? Will those other than module authors be prevented from accessing? If not, do you think it’s a distinction that will survive in the wild?
dimitarvp
Disagreed with @mischov and @brightball here.
-
In the case of inexperienced programmers: they simply look for the quickest way to get a job done without regarding much of anything else. So they definitely do not have a good reason for invoking private modules.
-
In the case of experienced programmers: they will have zero problems being explicit about their intention of using a private module – which is the whole point of this proposal.
In both cases, if the library doesn’t leave you with any choice but to use a private module then (a) you should try and communicate with the author to fix that or (b) will make a conscious decision to use a frozen version of the library since you rely on its private API.
I don’t see how implementing this proposal will change anything at all in legacy code. Moving forward, it allows for explicitness which I think we all around here agree is a good thing.
rodrigues
I prefer C.
D is too weak. For example, when a function is private, Elixir won’t allow me to just use it, and warn me. I think C is more in line with this. And having the :"Elixirp.(.*)" fallback seems to be as an OK tradeoff because of real world needs. The p in Elixirp makes it super easy to navigate through all the hacks.
I’d prefer having A’s @visible_to attribute, instead of passing it in the head. It seems it would be too common to have multiline defmodulep heads, because of reasonably fine grained visibility lists. And since when we’re defining module stuff, this usually goes through module attributes, @visible_to feels more idiomatic to me.
If someone doesn’t specify @visible_to, I guess we could go with the base namespace as a convention? This.Example.PrivateModule => default to [This]. I think this is nice when the user doesn’t care about using it inside the package, just doesn’t want to expose these modules to external code (in other namespaces).
Would be nice if mix docs would get an option to put in or not private modules (maybe default to false?).
josevalim
Creator of Elixir
It is because you should never have :"Elixirp.Foo.Bar" in your compiled code. It is very easy to spot those transgressions, it looks ugly, and it can be automated by tools like Credo. The concession exists for authors debugging and exploring the code, which means they are accessing it only in temporary sessions, such as inside IEx, and never as part of their compiled code.
joaoevangelista
I vote for C.
Because it doesn’t break the decisions made by the platform (repl, live debug, etc), and still make very clear to the user that it is a private API, and if wants to use it anyway it by its own risk by doing workarounds.
To the notation, I prefer the declaration to be explicitly on the head of defmodulep because it is required to be visible to something otherwise there is no point in declaring. But IMHO should be noted that defmodule is a macro that accepts arguments, and not a keyword in notation of other languages, so newcomers doesn’t get confused.
I’m ok with using require instead of alias, because you require that module to be in the same “scope”, and alias has the impression that the module is already in the same scope.
Thanks for that proposal 