Understanding @behaviour

[sushant12]

This particular file is a behaviour.

phoenixframework/phoenix/blob/v1.3.4/lib/phoenix/transports/serializer.ex#L1

And this is implementing it

phoenixframework/phoenix/blob/v1.3.4/lib/phoenix/transports/v2/websocket_serializer.ex

Now my question is, Why do I even need to use a behaviour? If I were to do this for the second link ^^ it will still work.

defmodule Phoenix.Transports.V2.WebSocketSerializer do
  @moduledoc false

  # @behaviour Phoenix.Transports.Serializer

  alias Phoenix.Socket.{Reply, Message, Broadcast}

  @doc """
  Translates a `Phoenix.Socket.Broadcast` into a `Phoenix.Socket.Message`.
  """
  def fastlane!(%Broadcast{} = msg) do
    data = Poison.encode_to_iodata!([nil, nil, msg.topic, msg.event, msg.payload])
    {:socket_push, :text, data}
  end
.
.
.

So what’s the point of using behaviour? The Phoenix.Transports.Serializer just defines functions without function body and leaves it to other module to implemente that function’s body.

What am I missing?

[Ankhers]

You can think of it like a contract that is visibile to the compiler.

Right now the behaviour defines a single function fastlane!/1. What if, in the future, that behaviour changed and added a new function. You would now have fastlane!/1 and foo/2. The compiler will let you know that you have a module that does not fully comply with the contract that has been written.

[hauleth]

@behaviour is just compiler annotation that helps you when you miss some functions required by the caller, it doesn’t change anything else.

[MrDoops]

The @behaviour redirects the dependencies allowing for swappable implementations of the interface. This means the Phoenix framework application code can depend on the Serializer behaviour/interface/contract instead of the WebSocketSerializer directly. So if there were a situation where you need a special serializer, you wouldn’t need to fork Phoenix or wait for them to change it. We would just need to implement another Serializer and configure Phoenix to use it.

[peerreynders]

FYI:

Behaviours in Javascript?

I really like to use behaviors in Elixir but now I have to work with Javascript so I don’t have them. Is there a library that would let me have this functionality? Or maybe there is a native solution for this?

History of Behaviours?

I know there are some Erlang old timers here, who might know - what is the history behind the behaviour syntax / idea? From a semantic point of view I could say that we could just send callbacks into a specific ‘behaviour’ function to setup / do our work for us… Perhaps they were easier to pick or learn than sticking lambdas in function arguments / dependency injection…? Did the idea originally come from elsewhere? OO interfaces, are obvious, but they don’t seem super compelling when you are…

Why are behaviour methods referred to as "callbacks"?

Coming from an OO background, my first reaction is to think of behaviours as interfaces. So it makes sense that a module must define one or more functions outlined in a behaviour if it wishes to implement that behaviour. So why in Elixir are the behaviour’s functions referred to as “callbacks”? In other languages, a “callback” has quite different connotations which have little to do with inheritance. In fact, the page at https://elixir-lang.org/getting-started/typespecs-and-behaviours.html h…

[sushant12]

thanks . You know what links to share