This idea is essentially implemented in the library Boundary GitHub - sasa1977/boundary: Manage and restrain cross-module dependencies in Elixir projects

Do you have any thoughts on how this proposal differs, beyond basically the implicit aliasing?

Please don’t. I know this isn’t a democracy but I vote against it.

At mobile so in short:

defmodule DataProcessingAliases do
  defmacro __using__(opts) do
    quote do
       alias MyApp.A
       alias MyApp.B
       alias MyApp.C
     end
   end
end

Now you can use DataProcessingAliases in the modules. Mixed ground between explicit and implicit…?

What would you gain with that? Imho at maximum a few lines less at the cost of macro in macro and a separate config.

Notice you can add multiple namespaces in a single file. So the example I gave can be copied over and over in a ‘config’ file.

As a benefit of the ‘manual macro’ solution you could also add common aliases not in the same ‘namespace’ such as Ecto.Repo. Enforce no aliases in the modules themselves and you get a boundary overview of all namespaces in a single file: every ‘out of pattern’ alias sticks out like a sore thumb.

defmodule Namespace do
  defmacro __using__(namespace) do
     Namespace.get(namespace)
   end

 def get(MyApp.Datastore) do
    quote do
       alias MyApp.DataStore.A
       alias MyApp.DataStore.B
       alias MyApp.DataStore.C
       alias MyApp.OtherMod.A # crossing boundaries
       alias Ecto.Repo
     end
  end

   def get(MyApp.OtherMod) do
      ….
    end
end

# usage

use Namespace, MyApp.DataStore

Ah, forgot about that. Need to expand it before passing it as function argument. Small change but then you can just use module names.