I didn’t have room for this in my book, Advanced Functional Programming with Elixir , but I still thought it was worth sharing on my blog.
2 Likes
I didn’t have room for this in my book
This topic is explored in more depth in my book
These two statements contradict each other, perhaps the footer on the blog is generic and doesn’t apply in this case?
I think behaviours also deserve a mention along with protocols. My experience is that it’s quite rare to write a protocol, compared to a behaviour.
For example, Eq could also be implemented using a behaviour:
defmodule Eq do
@callback eq?(a :: struct, b :: map) :: boolean
def eq?(%type{} = a, b) do
type.eq?(a, b)
end
end
defmodule Cat do
defstruct [:name, :microchip]
@behaviour Eq
def eq?(%Cat{microchip: a}, %{microchip: b}), do: a == b
end
iex(1)> Eq.eq?(%Cat{microchip: "foo"}, %{microchip: "foo"})
true
iex(2)> Eq.eq?(%Cat{microchip: "foo"}, %{microchip: "bar"})
false
1 Like
I really don’t know why there’s this behaviour fetish in the community. Protocols are for polymorphism. You use the protocol more or less directly. With behaviours you fill holes by providing callbacks. There is a framework, like the GenServer, which calls the module which implements the callbacks.
I’m not sure I see the point in a polymorphic equal? in the first place. One of the usecases for (dynamic) polymorphism is that the interface can exist independently from the implementations and implementations can independently maintained. Comparing a to b is not a problem well suited to that if any of a or b are of arbitrary type, because both types need to interact to be compared, hence they’re no longer independent.
Elixir actually kinda has a polymophic option in that domain: Enum.sort can receive a module to do the comparison between items in order to sort elements of a list. It’s not officially a behaviour, but uses the single @callback compare(a, b) :: :lt | :eq | :gt. The big difference on that one – it’s not polymorphism on a per type level. Each passed module needs to be able to deal with all elements it gets thrown at for comparison and you won’t be able to later bring in a new struct and make it be handled differently.
Good point on the contradictory phrasing, I trimmed these kinds of language-specific details from the book after some early feedback. The footer is just a standard note pointing readers toward the book if they want more depth, though it does not always apply perfectly.
I agree behaviours are important, but I would not say they implement polymorphism. They enforce a contract, but you still have to choose which module to call. To me, polymorphism means a function changes behavior based on the type of input, which is the protocol.
I’ve found myself deriving protocols a lot to sort of mimick Rails’ “concerns” (but in a functional way) and I’m wondering if it is the optimal way.
This is a simple example that for associating a note with any other record. I do add a direct fkey to the notes table for everything it can be assoicated with (avoiding the noteable_type and noteable_id pattern from other frameworks) but otherwise this mainly DRYs up having to mention these anywhere else (pattern matching to dispatch and typespecs mainly).
Here’s a stripped-down example:
defprotocol MyApp.Notes.Noteable do
def assoc_key(schema)
@impl true
defmacro __deriving__(module, opts) do
quote location: :keep do
defimpl MyApp.Notes.Noteable, for: unquote(module) do
def assoc_key(schema) do
get_assoc_meta(MyApp.Notes.Note, schema).owner_key
end
# Returns an Ecto Relation struct
defp get_assoc_meta(note, %noteable{}) do
:associations
|> note.__schema__()
|> Enum.map(¬e.__schema__(:association, &1))
|> Enum.find(&(&1.related == noteable))
end
end
end
end
end
defmodule MyApp.Notes.Note do
use MyApp.Schema
schema "notes" do
belongs_to :order, MyApp.Orders.Order
field :body, :string
end
def create_changeset(noteable, attrs) do
assoc_field = Noteable.assoc_field(noteable)
%__MODULE__{}
|> changeset(attrs)
|> put_assoc(assoc_field, noteable)
end
# ...
end
defmodule MyApp.Orders.Order do
use MyApp.Schema
@derive MyApp.Notes.Noteable
# ...
end
I wanted to key the sample small but there is also a assoc_key on the protocol which allow finding a note so we do:
order = Orders.get!(1)
notes = Notes.list_notes(order)
Again, I’ve been wondering about the general utility of this. We have a few of these things that all operate similarly so the abstraction feels worth it, but I’ve been wondering if I’m overlooking a simpler way (that is, outside of not using any abstraction at all).
Another I’ve seen stuff like this done in the past would be using macros to add list_notes to all contexts that have notes. I’ve found this can cause some nasty compile time deps and still requires setting up the schema stuff.
Anyway, I hope this is on topic 
Yes, we’re both solving the same problem: defining a default comparison for a type.
Here’s how I might implement the homogeneous sort:
def sort(list, ord \\ Funx.Ord) when is_list(list) do
Enum.sort(list, Ord.Utils.comparator(ord))
end
This lets the caller sort a list using the domain’s default ordering or pass in a different Ord when needed. It supports cases where the same type needs multiple comparison strategies. It also allows Ord composition, making it easy to build more complex ordering logic.
1 Like
I admit, I’m having a bit of trouble giving helpful advice on this one.
Your goal, as I understand it, is to reduce Ecto boilerplate, and you’re also, in a sense, extending Ecto’s macro system. Within your project, I don’t see a problem, except that it introduces a bit of indirection that you’ll need to make sure your colleagues understand.
From the perspective of protocols, what hung me up is that I was looking for the polymorphism problem you were solving, but in the end, I think you’re using the protocol more as a contract.
Is this generalizable? I see some tight coupling to your domain, so my answer would be probably not, but I might be misunderstanding.
Is there another way to solve it? Sure. But you’re approaching it from a Ruby context, and I don’t have enough Ruby experience to say whether there’s a better alternative through that lens.
2 Likes
That’s basically why I don’t want to use protocols and I am resisting them in work places. To me they are kind of implicit. A behaviour is an explicit function argument. I am tired of magic.
1 Like
Oh, interesting. You’re seeing magic where I’m seeing decoupling. I suppose it comes down to perspective.
Thanks for your reply!
Ruby’s “concern” concept is no more than a wrapper around mixins/traits, so it’s not really a Ruby specific thing but a general OO one. I guess I’ve never felt super confident of how to tackle things in Ecto that I would have used mixins/traits for in OO. Protocols always seemed the best fit. It essentially creates the classic “basic” difference between method and function calls:
resource.create_note(attrs)
and
create_note(resource, attrs)
Yes that’s really all it is. My thing is actually really an even more general abstraction around dynamically resolving an Ecto association. We have a bunch of these things and it ends up with a bunch of copy/paste code or being implemented slightly differently, so to me learning a tiny bit of reflection once is better than the inevitable inconsistencies that come about. YMMV, of course.
1 Like
Well behaviors are decoupling too, and are a touch more explicit. And they too are a contract.
That being said, these days I’m not as fussy about such things. If somebody from my team strongly prefers protocols then I’m forced to admit that, as a person without a strong opinion on the matter, there’s no reason for me to resist it.
1 Like
I do find protocols make a lot more sense for extending modules you don’t own. Of course this isn’t always the case with Elixir’s Enum being a prime example. Of course when you own the module you can just add all the function heads yourself and do essentially the same thing as a protocol, but I do find protocols pretty clean. It’s also quite a nice bonus that you get MyProtocol.t() for free 
1 Like
I would say protocols are for datatype polymorphism, often to get similar behaviour from different input data. Behaviours are for functional polymorphism, often to get different implementation details from similar contracts. Both can solve similar problems but have their own idiomatic wood grains to cut with or against.
Both involve functions accepting dynamic input that changes how the program executes: just as a function that accepts dynamic data may invoke a protocol to get different results, a function that accepts a dynamic module may invoke a behaviour to get different results.
Generally, unless we are doing supervision stuff/adapter work, our applications want to act similarly on different data more than we want them to act differently on similar interfaces, which is more of a library concern. Additionally, the type system and dialyzer work well enough with dynamic data types but dynamic modules is currently more of a black box for editor experiences. So I’d say the average application has more reason to be concerned with protocols than behaviours in practice, despite both mechanisms being open for extension in some sense to application developers.
But I would disagree with the claim that behaviours are not a mechanism for polymorphism; just a mechanism with different and less-common aims. I think my first paragraph there is a half-remembered direct quote from José, I’ll see if I can find the source. Some keynote maybe?
2 Likes
We’re probably just interpreting the term “polymorphism” a bit differently. I’m using the Strachey definition, where the runtime selects behavior based on the type of the input. Under that (admittedly narrow) lens, behaviours don’t quite fit, since the caller selects the module explicitly. But in the end, it’s probably just semantics.
2 Likes
