lud

lud

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

Most Liked

lpil

lpil

Creator of Gleam

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.

LostKobrakai

LostKobrakai

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.

lud

lud OP

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!

Last Post!

dimitarvp

dimitarvp

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.

Where Next? Top

Trending in Discussions Top

AstonJ
As the title says, please share what you’ve been up to with Elixir. Whether that’s been learning it, looking into it, making stuff with i...
2977 94592 917
New
cblavier
Hey there, It’s been more than a year since we started using LiveView as our main UI library and building a whole library of UI componen...
New
mudasobwa
I am happy to introduce the very α version of the new programming language compiled to BEAM. Welcome Cure. It has literally three kille...
New
heathen
Quite interesting article Google brought me. Didn’t find any mentions about it here. What do you think in general? Would you use togethe...
New
mhanberg
Hi everyone! The first release candidate for the Expert language server project is now available! We’ve published a press release detai...
New
AstonJ
Since we have deprecated our Erlang sections (as we have dedicated Erlang Forums now) let’s add this thread for those who’d like to post ...
New
Null-logic-0
What IDE or editor are you using for Elixir development? Personally, I use Zed, and I really like it, but sometimes I wish there were a ...
New

Other Trending Topics Top

JesseHerrick
Hey, I’m Jesse and I’m the main contributor behind Dexter, a full-featured, lightning-fast Elixir LSP optimized for large codebases. It s...
New
marciok
Hi there! We created Gust: A task orchestrator inspired by Airflow. For those who have never heard about Aiflow, it’s a Python-based wor...
New
jimsynz
Beam Bots (or just BB for short) is a framework for building fault-tolerant robotics applications in Elixir using familiar OTP patterns. ...
New
Dmk
Xamal is a deployment tool for Elixir apps that deploys native releases to bare metal servers over SSH. It’s a port of GitHub - basecamp/...
New
netoum
Corex is an accessible, unstyled UI component library for Phoenix that integrates Zag.js state machines using Vanilla JavaScript and Live...
New
webofbits
With AI doing more of the implementation work, I’ve been wondering how much coding I should deliberately keep doing myself. My main conc...
#ai
New

Latest on Elixir Forum

Elixir Forum

We're in Beta

About us Mission Statement

Options

Thread Display Mode




Thread Preview

Skip Thread Previews