Module definitions lost after `defoverridable`

[mguimas]

Environment

$ elixir --version
Erlang/OTP 21 [erts-10.2.3] [source] [64-bit] [smp:4:4] [ds:4:4:10] [async-threads:1] [hipe]

Elixir 1.8.1 (compiled with Erlang/OTP 21)

Current behavior

Given a file defining this module

defmodule MyOtherModule do
  def foo, do: "hello"
  IO.inspect Module.definitions_in(__MODULE__, :def), label: "Definitions 1"
  defoverridable [foo: 0]
  IO.inspect Module.definitions_in(__MODULE__, :def), label: "Definitions 2"
end

when compiled gives the following output:

$ mix do clean, compile
Compiling 18 files (.ex)
Definitions 1: [foo: 0]
Definitions 2: []
Generated things app

That is, the module definitions have been lost after the defoverridable clause.

Expected behavior

Declaring something as overridable should not affect the fact that it is a declared definition, consequently the output should be

$ mix do clean, compile
Compiling 18 files (.ex)
Definitions 1: [foo: 0]
Definitions 2: [foo: 0]
Generated things app

[mguimas]

It seems that it is the definitions in the list passed to defoverridable that are lost.

[josevalim]

Yes, good catch. this is by design, since defoverridable effectively removes the definition until a new one is added. We should likely document it better though. -- *José Valim* www.plataformatec.com.br Skype: jv.ptec Founder and Director of R&D

[mguimas]

Without looking into the code, it seems that there is a kind of "definitions collection" from where the overridable ones are removed. Instead of doing so, t would be preferable to allow a definition to be redefined in case it has an entry in an "overridable collection".

[mguimas]

@josevalim I don't know if it is "by design" in the sense that the observed behavior is meant for any developer to take advantage (I mean, developers outside of the core team), or if it is more "by implementation", and the implementation I suggested could inform how to fix.

In the first case, then it is as you say, it should be documented better because it involves unclear interference between two APIs, otherwise it should be fixed.

Thanks

[mguimas]

@josevalim One issue I find if we keep the current behavior, is that if someone adds a @before_compile hook which attempts to know which definitions are present in the module, this won't work if there is a defoverridable before the hook is run.

This example seems to show the need for reconsideration of the current implementation.

Thanks

[josevalim]

The opposite is also true, if something was marked as overridable and you want to know if the user overrode it or not, we can’t if we change the behavior as you propose. As already said, the current behavior is by design and we will document it. Changing it would be a breaking change. -- *José Valimwww.plataformatec.com.br <http://www.plataformatec.com.br/>Founder and Director of R&D*

[mguimas]

Ok. I suggest you then to include in the documention the following:

• how to get the list of all definitions in a module, despite they were added or not to defoverridable

• and, how to get the list of all overridable definitions in a module

[josevalim]

You can check for overridable?/2 to know if something is overridable but there is no mechanism to retrieve all of them. A proposal should be sent to the mailing list outlining the use case so we can add it to the language. -- *José Valimwww.plataformatec.com.br <http://www.plataformatec.com.br/>Founder and Director of R&D*

[mguimas]

And what about the first bullet point:

how to get the list of all definitions in a module, despite they were added or not to defoverridable

If we can know this, then using overridable?/2 seems to be enough to satisfy the second bullet point.

[mguimas]

I add two other use cases:

1. How to know if the current definition of a function was that added by use X, or that added by use Y, which overrode the one added by use X?

2. What if we want to forbid overrides of the definitions added by use X?

In my application I want to do point 2), and know if there are other definitions besides those added by use X.

[josevalim]

Can you please send a proposal to the mailing list? Try to be as descriptive as possible and use actual examples instead of X and Y. For example, the bug report you did on Module.create/2 is very good. Note, you usually know what was marked as overridable, so filtering your list through Module.overridable?/2 should be enough but we can only say for sure with a complete specification of the problem, which we don’t have. -- *José Valimwww.plataformatec.com.br <http://www.plataformatec.com.br/>Founder and Director of R&D*

[mguimas]

Ok, I will try to compose a clear one. Neverthless, despite the decision about the proposal, the before mentioned interference between defoverridable and Module.definitions_in, should, as you agreed, be documented clearly next to these two APIs. Thanks