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?