Proposal: Support for __PARENT_MODULE__ (or some other better name)

I don’t hate this and have found myself wanting it for cases like your first example. However, there is already confusion around there not actually being a module hierarchy and feel this could make it worse. It’s also something that won’t “just work” when you rename a module referenced by this.

Personally, I’m overall indifferent as I don’t find status quo to be too much of a pain.

Can you elaborate on that? I’m not sure I understood the point.

I would argue that you would get an error from the compiler and you would be able to easily fix the issue.

That module hierarchy in Elixir is an illusion and doesn’t exist. The . is lie! Lots of people don’t understand this. Nested defmodules already make this confusing enough.

Maybe this one wouldn’t be as bad as I thought. I’d have think more on this one as it feels like it could possibly cause subtle bugs where a rename could result in it calling another function that happens to have the same name, but maybe not

I should add that despite my indifference, I’d more than likely use this if it were available.

To expand upon this with examples…

Module A.B.C is not contained within module A.B nor A, they are completely separate modules whose names start the same.

Even when writing code such as:

defmodule A do
  defmodule B do
    def b, do: "b"
  end

  def a, do: B.b()
end

Module A.B is still not truly contained within module A (A.B is not a child of A) but the above works as a convenience.

Ah, ok, I got now what you meant, but that is just a technical detail IMO, in the end of the day devs (well, I just speak to myself on that) would read it as a hierarchy regardless.

But yeah, having a __PARENT_MODULE__ would give the wrong idea that the modules are a hierarchy.

Recently, I work in large repo and must to add alias too much. I wish Elixir has namespace for auto add alias (and maybe support for import/require/use).

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

Updated: I brought this into the proposal.

I do use __MODULE__ occasionally. Often like

alias __MODULE__, as: User

Even though it saves characters when writing, I find it sometimes makes reading code harder, whereas spelling out the name or fully qualified name would have been clearer. Example situations: grep results, reviewing git diff, casually browsing a large file. Those are add the cognitive burden to decode on my head “what module is this?”

I guess I’d feel similar about a __PARENT_MODULE__, with the additional trouble of making moving modules around to organize the illusional hierarchy require consideration for any usage of that shortcut. Depending on where the module name is used, this could pass unnoticed by the compiler, e.g. if the module is referenced as an MFA tuple.

AFAIK Erlang has a single module/atom namespace, and Elixir inherits that. This idea would be a separate proposal, different than the OP.

You can use the use macro to refactor your many requires, imports and aliases and implement something similar to what you are asking in “user land”. In fact, that’s what Phoenix projects are setup like when you scaffold them with phx.new.

For example, see: https://github.com/phoenixframework/phoenix/blob/V1.8.1/installer%2Ftemplates%2Fphx_single%2Flib%2Fapp_name_web.ex#L80-L97

In Controllers, Components, LiveViews, HEEx files, etc, the module Phoenix.LiveView.JS is available to use as JS without you having to alias it explicitly in every file.

While possible, this “magical” behavior is generally frowned upon, in preference of explicit code.

Thank you! My original idea namespace is a macro but need to work in compiler for sharing state or add specific thing.

I wrote to a separated OP.

Your example of alias __MODULE__, as: User would definitely make grepping harder, though that is really only because of the :as. Personally I think :as should really only ever be used for getting around naming conflicts.

Otherwise for me I find the cognitive burden goes the other way. when I see __MODULE__ I immediately think “current module.” On the other hand:

defmodule Foo.Bar do
  # ... many line
  def something(%Foo.Bar{} = bar) do
    # ...
  end
end

Seeing %Foo.Bar{} here immediately makes me think “a remote module” and it often takes me many moments to figure it out, which sucks when you’re scanning.