DEV Community πŸ‘©β€πŸ’»πŸ‘¨β€πŸ’»

DEV Community πŸ‘©β€πŸ’»πŸ‘¨β€πŸ’» is a community of 963,864 amazing developers

We're a place where coders share, stay up-to-date and grow their careers.

Create account Log in
Ilya Averyanov
Ilya Averyanov

Posted on

Protocols vs. Behaviours in Elixir: Additional Thoughts

Initial Thoughts

Recently I have read a fantastic article by Yiming Chen about Protocols vs. Behaviours in Elixir.

I want to thank the author for the great article β€” it clarifies a lot and strictly formulates some ideas that I couldn't acquire by myself.

Here I want to add some thoughts about the use cases of Protocols vs. Behaviours, precisely why we often still use Behaviours instead of Protocols.

My personal informal point is the following:

Protocols are suitable for pure interfaces (as stated in the article) of pure data structures.

When we try to use Protocols with something that deals with side effects, namely processes and message sending, we often start to feel awkward.

The reason is that things with side effects are built with OTP pieces (GenServer's), and:

  • we feel comfortable following its original design;
  • delayed initialization is essential, and it doesn't look fine with Protocols.

Illustrations

Let me illustrate that.

I develop a small library SMPPEX, and there I have a module and Behaviour named Session. It's only important that it wraps and extends GenServer, i.e.

  • It specifies callbacks, such as init, handle_call, ..., and some own ones: handle_pdu, etc. They operate as usual: init initializes some state, and then it is passed to the callbacks.
  • It implements interface functions such as Session.start_link, Session.call, Session.cast, as well as Session.send_pdu, etc.

Naive Design

When I first tried to implement this module, I tried to apply the idea of Protocols.

I made a Protocol, like SessionState, which specified callbacks:

defprotocol SessionState do
  def handle_call(st, from, message)
  def handle_pdu(st, pdu)
  ...
end
Enter fullscreen mode Exit fullscreen mode

To use Session, I would do the following.

First, implement SessionState.

defmodule SessionStateImpl do
  defstruct [...]

  def new(args) do
    ...
  end
end

defimpl SessionState, for: SessionStateImpl do
  def handle_pdu(st, pdu) do
    ...
    {:noreply, new_st}
  end
end
Enter fullscreen mode Exit fullscreen mode

Then create an instance and pass it to Session:

st = SessionStateImpl.new(args)
{:ok, pid} = Session.start_link(st, ...)
Enter fullscreen mode Exit fullscreen mode

At first glance, it may seem that everything is excellent, but trying to make a PoC app, I ran into an issue. It is that in OTP the context of initialization is essential.

When implementing GenServers, users often like to do something like:

def init(opts) do
  ...
  timer = :erlang.start_timer(@interval, self(), :tick)
  ...
end
Enter fullscreen mode Exit fullscreen mode

We need to know the session's PID to set up timers or do other useful stuff, like global registration, etc.

But we create SessionStateImpl (call SessionStateImpl.new) before starting Session and don't have a place to do that.

Probable Improvements

Solution 1

We may defer SessionStateImpl creation and initialization so that Session internals could do that.

# st = SessionStateImpl.new(args)
{:ok, pid} = Session.start_link(SessionStateImpl, :new, args, ...)
Enter fullscreen mode Exit fullscreen mode

But I don't think that we used Protocol and got rid of passing module and state around to start to pass them again :)

Solution 2

We may defer initialization and make it be a part of SessionState Protocol. The problem is that we can't use Protocol without the underlying struct, so we should do something like:

defprotocol SessionState do
  ...
  def init(uninitialized_st, args)
  ...
end

...

defimpl SessionState, for: SessionStateImpl do
  def init(uninitialized_st, args) do
    ...
    # some initialization
    ...
    {:ok, initialized_st}
  end
end

...

st = %SessionStateImpl{}
{:ok, pid} = Session.start_link(st, args, ...)
Enter fullscreen mode Exit fullscreen mode

Now we have to pass uninitialized states around β€” the idea I do not like much.

Using Behaviours

Playing around with this, I concluded that I was doing something strange and would confuse possible users.

I moved to traditional Behaviours and got the feeling that everything was right :)

Successful Example of Using Protocols

Once I was developing a system analyzing git commits. The commits were fetched from Bitbucket API and represented huge JSON chunks of data passed around.

I added Commit Protocol and implemented it for APICommit:

defprotocol Commit do
  def author(commit)
  def author_email(commit)
  def added_files(commit)
  ...
end
Enter fullscreen mode Exit fullscreen mode

Later I had to combine such commits with ones saved to DB differently. But, thanks to having a Protocol, this logic didn't have to treat them differently after I implemented Commit for DBCommit data structure.

This case of Protocol usage is an example of dealing with pure data structures, and it proved to be successful.

Conclusion

The problem of selecting between Behaviours and Protocols in Elixir is exciting and challenging at the same time.

I hope to see more examples of successful and unsuccessful attempts of modeling using Behaviours and Protocols.

Top comments (2)

Collapse
 
dsdshcym profile image
Yiming Chen • Edited on

Thank you! I'm glad to see my blog post to be inspiring!

I think maybe handle_continue callback can be useful here πŸ€”
pass/intialize a pure data structure in the init callback, then call start_timer in the handle_continue callback?

Collapse
 
savonarola profile image
Ilya Averyanov Author

Thanks for the feedback!

That should work, but does not completely resolves the thing that bothers me the most: that we still have two places where initialization happens: when creating a data structure and then some "additional" initialization in handle_continue. Maybe I am too spoiled with traditional OOP languages, and this is OK :)

🌚 Browsing with dark mode makes you a better developer by a factor of exactly 40.

It's a scientific fact.