This sounds like the situation defoverridable is intended for.

Every time I’ve personally started off with a protocol for some generic piece of functionality, I’ve eventually switched to a behaviour. I believe they are both more explicit and more flexible, and lend themselves well to the defoverridable strategy that @al2o3cr mentioned.

defmodule AdminResources.User do
  use Admin.Resource, schema: App.Accounts.User
  # defines default impls for all required callbacks

  # override where needed
  @impl true
  def whatever do
    …
  end
end

That was yesterday, today is a new day!

Which made you valuable for the community already. Take credit

You have stumbled upon on the many faces of the expression problem!

One doesn’t need to squint hard that the notion of your architecture to be truly scalable under development (what I mean here, strictly, is to guarantee that at no point in time you have added a new data type such as App.Accounts.User, but forgot to implement some method such as form and, conversely, you have added some method such as form and didn’t match some of the data types such as App.Accounts.User), is the same as the notion of adding a new function and a new type case at the same time.

I think what the colleagues who have answered with defoverridable suggestion imply is something like the idea from the post-scriptum of this post, which is “just being able to scale code base along one function / type case axis is enough for scalable code bases that are also ergonomic”.

That said, defoverridable is not a panacea. It allows you to add more types easily, but based on your question you seem to be more concerned about adding more functions. Furthermore, you venture into the dangerous waters of default implementations which, if unconstrainted, can quickly turn unusable. Ask yourself when have you last seen a useful default implementation that survives class inheritance?!

This is why, I would argue that what you actually need a hierarchy of protocols. One could say, you need traits! Now if you’re able to define your default implementaitons in terms of existing traits, these implementations shall trivially survive subtyping!

If you wonder where can you get hierarchical traits in Elixir, type_class library has got you covered!
What’s more, is that you can be principled about trait methods that you define and add properties for the traits that shall be checked at compile time.

Finally, on ergonomics that you desire.

Consider you have:

defclass A do
  def f(x), do: x
end

defclass B do
  def g(_x, y), do: y
end

defclass C do
  extend A
  extend B
  def h(x, _y), do: x
end

The UX you want is

definst C, for: X do
  def f(x), do: x.c
  def h(x, y), do: {x.c, y}
end

Sadly, the best type_class can do is:

definst B, for: X
definst A, for: X do
  def f(x), do: x.value
end
definst C, for: X do
  def h(x, y), do: {x.value, y}
end

I sketched out an implementation plan for shallow dependency instance definitions here.

In general, I would strongly suggest you having the safest architecture that enforces completeness of function implementations over data types over both developer’s user experience and trying to chase the expression problem. Whatever it means for your particular problem.

@katafrakt there are a couple of suggestions in this thread you might want to check out: Overridable functions in protocol implementations? - #6 by Ajwah

That said, when I created LiveAdmin I did consider integrating directly with the Ecto schema modules themselves to handle config, but I ultimately decided against it because I wanted something as flexible and light-weight as possible. Personally I preferred to keep that noise out of the application business logic, but other users might prefer to have it in the contexts, or separate per-schema modules, or whatever. It’s certainly true that eventually this can lead to unwieldy configs. However, since the config is just a list, there is nothing to stop the user from leveraging whatever language features they want to specify their config implementations consistently for all the schemas, and furthermore, to pass the result via app level config, rather than per-schema configs in the router. If you wanted to use protocols to contain your config logic, you could do something like this:

config :live_admin, 
  label_with: {Admin.Resource, :label, []}, title_with: {Admin.Resource, :title, []}, ...

and then the router would only need the list of schemas, which is also something you could generate dynamically.

Admittedly, not all config is currently so conducive to that approach and would need additional effort to generate, but I think it should be doable if desired. Maybe that is something I should take a look at formalizing a bit more.