Inheritance in Elixir

fceruti

I’m working on a cool library (news about that in a few weeks ), and there’s no sugar coating this: I really want to use inheritance.

I’m no Elixir n00b, at least not completely. I’ve enjoyed the functional paradigm shift very much, but in this particular case, I can’t help but feel like I’m jumping all kinds of hoops just to emulate what simple inheritance stuff would fit perfectly.

Let me describe the problem, then the best solution I’ve come up with, and I hope you can help me come up with a better one.

So, in this library, there’s lots of configuration to do. Most of this configuration will be written by the author of the library, lets call them starting points, and there are many of them. Users can use one of these starting points and just modify whatever they want to change and keep the rest. A config that uses a base “template” can also be a template for another config, and they would catch these config definitions in a cascade manner.

That’s probably the longest I’ve written about inheritance without mentioning it.

Right now I’ve got something like this:

defmodule Config do
  @callback __attr_value(atom(), atom()) :: atom()
  @optional_callback __attr_value: 2

  defmacro __using__(_opts) do
     quote do
        @behaviour Config

         def attr_value(category, item) do
           try do
               __MODULE__.__attr_value(category, item)
           rescue
              _e in [UndefinedFunctionError, FunctionClauseError] ->
                variables = __MODULE__.__info__(:attributes)
    
                if parent = Keyword.get(variables, :parent) do
                  parent.__attr_value(category, item)
                else
                  default_value(category, item)
                end
           end
         end
     end 
  end
end

defmodule BaseConfig do
   use Config

   def __attr_value(:category, :name), do: :my_value
   def __attr_value(:category, :picture), do: :my_picture
end
   
defmodule ChildConfig do
   use Config
   @parent BaseConfig

   def __attr_value(:category, :name), do: :another_value
end

It works, but I don’t know, I’m feeling uneasy with it.

What do you think? Have you seen this in the wild? Is there a better way?

6 comments

#macros #composition

0 1581 6

2023-09-05 05:55:58 UTC

Showing Posts 1 to 6

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

dimitarvp

Quick shot at this: why not use defdelegate in the derived (child) configs?

Post #1

fceruti

hehe nice! That’s it. Inheritance solved!

Now it looks like this

defmodule MyConfig do
  @callback attr_value(atom(), atom()) :: atom()
  @optional_callbacks attr_value: 2
end

defmodule BaseBaseConfig do
   @behaviour MyConfig

   def attr_value(:category, :name), do: :base_base_name
   def attr_value(:category, :picture), do: :my_picture
end

defmodule BaseConfig do
   @behaviour MyConfig

   def attr_value(:category, :name), do: :base_name
   defdelegate attr_value(a, b), to: BaseBaseConfig
end
   
defmodule ChildConfig do
   @behaviour MyConfig
   def attr_value(:category, :name), do: :child_name
   defdelegate attr_value(a, b), to: BaseConfig
end

Now a tiny little detail. How can I “annotate the information” of who I’m delegating to, at the top of the module instead of the bottom.

I’m thinking something like using a macro that injects at the end what is defined at the top. Is that possible?

Post #2

cmo

I presume you mean something more advanced than a module attribute?

defmodule ChildConfig do
   @behaviour MyConfig
   @delegate BaseConfig
   def attr_value(:category, :name), do: :child_name
   defdelegate attr_value(a, b), to: @delegate
end

Post #3

fceruti

Oh man, thanks this is awesome. I got lost in a sea of macros when the solution was so simple

Thanks!

Post #4

eksperimental

First, do not use Config as the name for your behaviour since it is a module in Elixir.

Then I would work with module attributes and do compile time checks.
What i usually do is create functions in the behaviour module that are called by default with the default implementations defined in __using__/1. Also look into how to play with òptions passed to this macro.
Then also make use of defoverridable/1 to let the user rewrite the default implementation.
You should be covered by all this.

Post #5

krasenyp

This is what I’ve implemented numerous times and works well. Something similar is shown in the article Macro Madness: How to use `use` well - DockYard.

Post #6

— All posts loaded —