This is really interesting idea!
I’m not sure about it. On one hand it could be probably nicer for iex
sessions (not sure about it), but on another I would like to see a module which is only accessible for specific library/scope.
What would happen if somebody would do:
defmodulep NotMyLibrary.Private, visible_to: [NotMyLibrary] do
# …
end
and then I would do something like:
defmodule MyApp do
# …
end
# …
defmodule NotMyLibrary.SimpleHack do
require NotMyLibrary.Private, as: Private
# …
end
Is it possible to add something like:
defmodulep NotMyLibrary.Private, ensure_app: [:not_my_library], visible_to: [NotMyLibrary] do
# …
end
so in case of compile time definition of NotMyLibrary.SimpleHack
in my_app
app we would receive error/warning like there is one on overriding modules.
Even if DDD
is different for each compilation then it’s possible to find it like:
defmodule Example do
def sample(module) do
source = Keyword.keys(:code.all_loaded())
regex = ~r/\Amodulep_[0-9]+_#{to_string(module)}\Z/
matcher = &String.match?(&1, regex)
source |> Enum.map(&to_string/1) |> Enum.find(matcher) |> String.to_existing_atom()
end
end
real_module_to_alias = Example.sample(Foo.Bar)
Of course it’s not as safe as depending on official way, but I believe that in such way we could guess real full module atom. Hope I did not missed anything here.
I have also two questions here:
-
Would be there easy way to use private modules inside
iex
session? It would be awesome if it could be possible only foriex
session started only for restrictedapp
. -
How
Elixir
(and thereforeex_doc
) would handle@moduledoc
and@doc
attributes inside private modules? I see here a nice win-win to close@docp
and related topics.
It would be awesome if it will be introduced into Elixir
core as people would be forced to stop depend on private APIs.