Protocols vs behaviors?

[Alex Shneyderman]

I am starting to look into protocols. There seems to be an overlap of capabilities between the two. Is there guide somewhere the compares and contrasts the two. I.e. when would I absolutely use protocol, when would I absolutely use behavior, and what woud be the case where either one is going to be fine?

Cheers,

Alex.

[Peter Hamilton]

Are you passing around data or modules?

For a behavior like gen server, you are launching a new process by providing the module. The module can be anything that implements the gen server behavior.

For a protocol like Enumerable, you are passing in data. You can pass in any data that implements the Enumerable protocol.

--
You received this message because you are subscribed to the Google Groups "elixir-lang-talk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to elixir-lang-ta...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Saša Jurić]

To add to Peter's answer, I recently answered a similar question on SO: http://stackoverflow.com/questions/26215206/difference-between-protocol-behaviour-in-elixir

and Robert has chimed in with an additional comment.

[Eric Meadows-Jönsson]

A protocol enables polymorphism. With protocols can define an interface that different types can have different implementations of. A behaviour on the other hand defines an interface for modules.

Behaviours are just a way to document an interface for modules and have the compiler tell you if you don’t adhere to that interface, there is no logic in behaviours. Protocols have logic to dispatch to an implementation depending on the type of value you pass it.

I would say that there is no overlap between when I would use behaviours or protocols, even though they may seem similar in functionality. Use protocols when you want to have different implementations depending on the type of value you are working with (see Inspect and Access in stdlib). Use behaviours when you don’t really have an associated type (for example inspect has the type you want the string representation of, access has the type you want to access keys on).

An example of a behaviour could be the interface for database adapters or the interface you have to adhere to when implementing a GenServer.

​

--

You received this message because you are subscribed to the Google Groups "elixir-lang-talk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to elixir-lang-ta...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
Eric Meadows-Jönsson

[José Valim]

Just to expand on the previous answers, we can split Elixir code in three categories: processes, modules and data. They are all interconnected: processes runs the code defined in modules that manipulates data types.

Each of those 3 categories have their own way of doing polymorphism.

1. When you write a code like this:

    send some_pid, {:some, :message}

You are saying: "I don't really care what some_pid is, as long as it handles the {:some, :message} accordingly".

2. When you write code like this:

    some_module.some_fun(arg1, arg2, arg3)

You are saying: "I don't really care what some_module is, as long as it implements some_fun/3 accordingly".

3. When you write code like this:

    MyProtocol.protocol_fun(some_data, arg1, arg2, arg3)

You are saying: "I don't really care what some_data is, as long as it implements MyProtocol accordingly".

Unfortunately, Erlang/Elixir does not provide a way to document the messages between processes (case 1). Behaviours allow us to document the functions and return types in case 2. Protocols allow us to define the API for case 3 which can be further documented with specs (similar to behaviours).

José Valim

www.plataformatec.com.br

Skype: jv.ptec

Founder and Lead Developer

[Alex Shneyderman]

Thanks all for the answers! They are all awesome ;-)