I really like the idea, but I think that @impl might get confused with something related to protocols because of Kernel.defimpl/3, Protocol.assert_impl!/2, and Protocol.extract_impls/2 beeing the only things mentioning “impl” in elixir until now. Therefore I’d opt for something like @override as in Java.

[quote=“josevalim, post:1, topic:3338”]
Therefore we propose the addition of defoverridable BehaviourName, which will make all of the callbacks in the given behaviour overridable. This will help reduce the duplication between behaviour and defoverridable definitions and push the community towards best practice. Therefore, instead of:[/quote]

defmodule GenServer do
  defmacro __using__(_) do
    quote do
      @behaviour GenServer

      def init(...) do ... end
      def terminate(..., ...) do ... end
      def code_change(..., ..., ...) do ... end

      defoverridable init: 1, terminate: 2, code_change: 3
    end
  end
end

We propose:

defmodule GenServer do
  defmacro __using__(_) do
    quote do
      def init(...) do ... end
      def terminate(..., ...) do ... end
      def code_change(..., ..., ...) do ... end
      defoverridable GenServer
    end
  end
end

I think this is a good addition as I’ve incurred into a situation where I had to manually override all callbacks of a certain Behaviour in several modules. However, I’ve got a question and a suggestion:

• Why does the new example lacks @behaviour GenServer? Does the usage of the new defoverridable GenServer also includes the @behaviour tag?

• I believe the proposed defoverridable GenServer may cause a certain misdirection to the user since there’s the Module GenServer and the Behaviour GenServer (in this concrete example, but can be applied to other ones I guess). Of course you can’t override Modules, but I believe a more explicit way to inform it is actually the Behaviour that is being overridden could be helpful (specially if my previous question holds).

The reason why we chose @impl is precisely because a protocol is implementation of callbacks. So they are not different, they are exactly the same. So you can think defimpl/3 is about a module of individual @impl.

The reason we rejected @override is because @impl true does not only apply to defoverridable but to any Behaviour. Given when implementing a behaviour without defoverridable there is nothing to override, I don’t think @override would be a good match.

In any case, we are open to discuss alternatives to @impl, but I don’t think @override in particular is a good fit.

Yes but after your questions I realize it can be a source of confusion. I will amend the proposal to not do that.

I think the main reason people are doing crazy macro things around behaviours is that there’s no good guide or example on how to do this.
So when people want to give an interface similar to GenServer with some additional callbacks, they define regular handle_call functions inside __using__ and make things overridable. This has a lot of issues, poor debugability being probably the biggest one.

I think education could go a really long way in here, so I’d like to propose attaching creating a “Write your own behaviour” guide to the proposal.

@michalmuskala You hit the nail on the head, in my opinion. I know Elixir doesn’t strive for being an OO-like language but I think we can all agree some polymorphism is very useful. I’d like to see Elixir be able to do duck-typing like Golang does.

@josevalim To me, defoverridable intuitively means “I am declaring an overridable function/module right here, where I am typing in this source”. It doesn’t sound like “I am implementing a function/module which are overridable and declared somewhere else; here I am just providing their implementation or override of their defaults”. That’s subjective of course.

Is Golang’s transparent duck-typing impossible for Elixir? If my module implements 3 separate (and non-intersecting) function sets, can a function accepting any of those 3 modules transparently recognize my module as any of them, without any statements that my module implements 3rd party overridable functions?

Apologies if it’s a very obvious / dumb question, I admit I am pretty much oblivious about discussions on the mailing list.

I am unsure of what you are asking. If you are talking about data types, Elixir provides both closed ad-hoc polymorphism via pattern matching on function clauses and open ad-hoc polymorphism via protocols (which are close to interfaces). Parametric polymorphism (aka generics) is not a concern, as Elixir is a dynamic language, but that’s not supported by Go anyway.

The other form of polymorphism common to languages is subtype polymorphism but I don’t think that would apply to Elixir or Go.

Yup. We already have a guide on behaviours and we can further extend that. The plan was also to extend the defoverridable implementation to point towards best practices, like backing up your overridable functions with behaviours, which we currently don’t.

Both interpretations are correct. The point is, if you are providing overridable functions because those functions are meant to be called by external modules, which the majority of uses of defoverridable, then it is a best practice to explicitly document the contract you expect the overridable functions to implement, and that’s done with behaviours.

I keep getting mixed up between behaviours and protocols. My mistake. I did additional reading and I am withdrawing my original questions. Apologies!

I really like these changes, as it really makes it more explicit what is going on.

I do have a question: How can we properly migrate to this new way of doing things, while for the time being keeping our code backwards-compatible with older Elixir versions?
Use @optional_callbacks but also write defoverridable for backwards compatibility? Or is there a way to switch between these statements at compile-time based on the Elixir version, to make it very explicit that part of it is legacy-support that might be removed in the future?

In general I like the direction (simplifying and allowing for optional callbacks), but I must admit that @impl true really sticks out as a sore thumb for me. It’s one of those optional things that people are either going to forget, apply only on half the code base, or that certain developers will ignore or over-use. It also separates the behaviour inclusion into different parts in the module.

defmodule Foo do
  use MyBehaviour
  use OtherBehaviour

  @impl true # implemementation for what? MyBehaviour or OtherBehaviour?
  def bar, do: :ok

  @impl true
  def baz(x, y), do: {x, y}

  def qux, do: :ok  # Is this a callback? Is it used?
end

I think it poses the following problems:

• Denoting which behaviour the implementation is for (one can mix several behaviour implementations in the same module)
• The behaviour usages is now split out over the module instead of defined in one place
• It can be forgotten
• It adds noise to the code

In the end, does it really add a benefit? It just gives some feedback when used with a callback implementation with the same name but different arity, and that’s it. In no other cases is it useful (same arity, different name or mismatch in pattern matching).