Proposal: Add support namespace for module

Chat & Discussions Proposals: Ideas
1

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.
2

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?

6 Likes
3

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

3 Likes
4

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

1 Like
5

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.

6

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
1 Like
7

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.

8

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.

9

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
10

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

1 Like