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.

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!

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.

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.

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

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.

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.