Protocols vs interfaces

Chat / Discussions
,
1

Hello,

When using protocols, most complex code used in defimpl MyProtocol, for: MyStruct needs to use multiple helper functions from the MyStruct module.

So what I generally end up with is a dummy defimpl that just forwards all calls to the implementations located in MyStruct, so those implementations can just use any local function and the exported API of MyStruct can change without worrying of modifying the protocol implementation accordingly.

Some might say that it is OOP to tie implementation to the data structure, but OOP is more like tying the implementation to the state. In my case, this is just the same as a regular defimpl with one more level of indirection.

The problem is that it is tedious to write all those forwarding defimpl so I tend to just write an implementation for Any and write all the forwarding calls in the __deriving__ macro.

And finally yesterday night I just wrote a macro that takes a protocol name and the defs do block, creates the protocol along with the implementation for Any containing the forwarded calls and the actual implementation for Any (that just raises).

This is basically an interface.

So I call this:

require Ark.Interface

Ark.Interface.definterface MyProtocol do
  @spec get_stuff(t, binary) :: {:ok, binary} | {:error, :not_found}
  def get_stuff(t, path)
end

And I’m done, I can just @derive the protocol for some structs and implement the callbacks in the struct’s module.

The interface is an actual Elixir protocol that can still be implemented with defimpl for any type (well, except for the Any type :D).

What do you think about that ?

My main gripe with Elixir protocols is just that a defimpl embedded in a module cannot access local functions.

You have to write:

defmodule X do
  defstruct [:val]

  def new(n) when is_integer(n) do
    %__MODULE__{val: n}
  end

  def wrap(n) do
    "the val is #{n}"
  end

  defimpl Prot do
    def to_s(%{val: n}), do: X.wrap(n)
  end
end

instead of this:

defmodule X do
  
  @derive Prot
  defstruct [:val]

  def new(n) when is_integer(n) do
    %__MODULE__{val: n}
  end

  defp wrap(n) do            # defp
    "the val is #{n}"
  end

  @impl Prot
  def to_s(%{val: n}), do: wrap(n)
  
end
2

While I can see all of your mentioned pain points I don’t think they should be changed. The (primary) interface for a protocol is calling Prot.to_s not having a X.to_s. I’m not sure why you’d want to have X.wrap as a private function in the struct. Either you keep Prot and X independant, but then X needs to expose all the functionality Prot needs (publically) or you don’t and you can just implement Prot.to_s directly by moving the implementation of wrap into the protocol.

Elixir itself even goes so far in that DateTime.to_string and String.Chars.to_string(date_time) duplicate the implementation. The latter doesn’t call DateTime.to_string.

1 Like
3

I’m not sure why you’d want to have X.wrap as a private function in the struct.

Well wrap is a (bad) example on how sometimes to providing an implementation for a protocol requires a deep knowledge of the data structure and usage of functions that we do not want to be exported.

But that makes me wonder if having protocol implementations to rely only on public functions should be a goal. I guess so for “tooling” protocols like String.Chars, Inspect or Jason.Encoder. But in the case of protocols used as pseudo interfaces to provide polymorphism (think MyApp.Storage with ETS, mnesia and Postgres adapters) then I would say that yes, X needs to expose all the functionality Prot needs publically.

Elixir itself even goes so far in that

Ok but those also are simple forward calls.

While I can see all of your mentioned pain points I don’t think they should be changed.

Acutally I agree, it is flexible as it is. But I wonder if it is common practice to just use defimpl as an indirection layer.

edit: And thanks!

1 Like
4

Yes, but that one still involves the “deep knowledge of the data structure” that you mentioned.

To me the difference is mostly the implementor. If both the data structure and the protocol impl. are of the same project (same mix project / repo, not group of projects) then it’s fine to have implementations be aware of internal details. If that’s not the case then the implementations should work with publically exposed data/functionality only.

5

I like to always expose a public function that has the same functionality as the protocol, but minus the generic runtime dispatch functionality as the protocol.

defmodule X do
  defstruct [:val]

  def new(n) when is_integer(n) do
    %__MODULE__{val: n}
  end

  defp wrap(n) do
    "the val is #{n}"
  end

  def to_s(%{val: n}) do
    wrap(n)
  end
end

defimpl Prot, for: X do
  def to_s(x) do
    X.to_s(x)
  end
end

This keeps the internals private, and also gives you a specialised function you can use for when you want to be a little clearer about what the value is.

Here the only thing the protocol definition does is register the type with the dispatch mechanism.

3 Likes
6

Seems you guys are more or less after duck typing and protocols are kind of getting in the way?

7

Not sure what you mean by that! Generally we want an interface because what we actually need is a behaviour but each implementation has state. I am currently working on a personal project where I have a credentials store. In tests, the state is a map of strings but in prod it will be either be a database or a file. So your behaviour needs to keep that map, or the table details, and it is abstract from the outside. But a behaviour would not cut it because I do not want a process (though some implementations states could be a pid).

Now the credentials store could be a simple fun ; you pass the credentials name you want and it returns the token. In that way, using lambda functions provides actually better polymorphism than objects. Alas, you not only want get_gredentials but also put_credentials, list_credentials, has_credentials?, etc…

You can always pass funs like this:

  defp wrap_creds(creds) do
    fn
      :get, name ->
        {creds[name], creds}

      :put, {name, token} ->
        creds = Map.put(creds, name, token)
        {creds, wrap_creds(creds)}

      :has?, name ->
        {Map.has_key?(creds, name), creds}
    end

But those are poor man’s objects.

Another example I had with my team was to extract environment variables from .env files, gitlab CI yaml files, docker compose files, env documentation toml files, application.properties java files. Here the different data structures are only created to support the protocol, they don’t do anything else besides listing, getting and putting the keys.

For those cases I do just what Ipil does but now with a shortcut macro.

8

Not sure I get your scenario. If f.ex. your credentials store is hitting the network your beautiful abstraction falls apart because you’ll either have to add handling of network errors or you’ll opt for ignoring errors. The former is OK but it might be an overkill if there’s also an alternative implementation with plain functions, the latter is definitely bad.

IMO the way to go here is to draw some lines and boundaries first.

There’s nothing wrong with that. Having some OOP by emulating and limiting it is what an ideal OOP looks like to me. Full-fledged OOP is too much for most tasks, especially in an FP language.

1 Like