Proposal: Add support namespace for module

manhvu

In a large repo, working with module need to add alias too much is quite annoyed and not good for organizing code.

I think better add support for namespace can bring more convenient for dev.

This is a basic example for namespace cross multi modules.

Example:

defmodule MyApp.A do
  namespace MyApp.DataProcessing

  def a do
  # do somethings
  end

  defmacro macroA(name, opts) do
    #...
  end
end

defmodule MyApp.B do
 namespace MyApp.DataProcessing

 def b do
  # somethings
 end
end

defmodule MyApp.C do
  namespace MyApp.DataProcessing

  def do_something(data) do
    data
    |> A.a()
    |> B.b()
  end

 A.macroA :wrapper, type: :json
end

LS can easily to suggest dev in a namespace.

Pros:

Less typo like add alias for module.
Make code clean than before.
Better for LS suggest in case work in namespace.

Cons:

Make complicated if bring support for import, require or use.
Can make dev confused.

9 comments

#syntax

0 751 9

2025-10-23 14:42:36 UTC

Showing Posts 1 to 9

Show Best Posts
Show All (oldest first)
Show All (newest first)

benwilson512

Author of Craft GraphQL APIs in Elixir with Absinthe

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

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

Post #1

FlyingNoodle

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

Post #2

BartOtten

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…?

Post #3

manhvu

Thank you for your suggestion, I have an idea wrap a macro for this but need a manual job like put all module name to one place like config for expand macro later.

Post #4

BartOtten

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

Post #5

mudasobwa

Creator of Cure

The democracy is all about the illusion your vote counts. To vote per se you don’t need a democracy, colorful beans and a couple of amphorae suffice.

Post #6

manhvu

Oh, I like this way than mine. Thank you so much!

A little of bit more about my case. I usually work with quite large repos, sometimes my project is an umbrella project (after that maybe I split it to multi nodes). Too many modules with long name make me feel tired for remember and repeat again and again in each module. That way I’m finding a new way when work with Elixir.

Post #7

manhvu

MyApp.DataStore is alias and need to unquote for using. For simplicity, I created a module like:

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

  def get(:space_a) do
     quote do
       alias MyApp.DataStore
       alias DataStore.A
       alias DataStore.B
       alias DataStore.C

       alias MyApp.OtherMod.A # crossing boundaries
       alias Ecto.Repo
     end
  end

  def get(:space_a) do
      #….
  end
end

# usage

use Namespace, :space_a

Post #8