tcoopman
I don’t think the following is possible, but going to ask for possible solutions.
I have the implementation of a Protocol with 5+ functions with 10+ modules implementing them.
A lot of these implementations have a default implemenation, like they don’t need to do a lot.
The problem I have is that I need to add a new function to the protocol, but the only way to do that is to update all the functions in 1 go. I’d rather not to that, as I first want to validate if the thing I’m trying is actual a valid thing to do.
So, what I’m wondering is, can I do something like defimpl for only 1 function of a protocol.
I guess that’s not possible, but I was wondering how you would solve something like this.
FYI, this is the current protocol:
defprotocol DomainModelling.Block do
def advance?(data)
def evaluation_pattern(data)
def evaluate(block, params, session_state)
def state(block)
def dependencies(block)
def classify(block)
end
The reason I chose for a protocol is because I want to be able to add extra implementations, without the code using it being impacted. For example I have test modules that implement the protocol.
I guess one possible solution, is to just skip the protocol completely and use duck typing.
Any other ideas? It’s possible that I just need to rethink my design.
Where Next?
Trending in Questions
Other Trending Topics
Latest on Elixir Forum
Sponsor Spotlight
Catch errors, track performance, monitor hosts and more.
Categories:
Sub Categories:
Forums
Popular Tags
- #ecto
- #liveview
- #troubleshooting
- #learning-elixir
- #library
- #deployment
- #erlang
- #testing
- #genserver
- #mix
- #absinthe
- #remote-other
- #otp
- #plug
- #how-to-question
- #macros
- #postgres
- #elixirconf
- #channels
- #exunit
- #discussion
- #code-sync
- #podcasts
- #javascript
- #onsite
- #dialyzer
- #docker
- #authentication
- #umbrella
- #full-time-contract
- #podcasts-by-brainlid
- #ecto-query
- #ai
- #elixirconf-us
- #blog-post
- #elixir-ls
- #phoenix_html
- #iex
- #graphql
- #genstage
- #websockets
- #supervisor
- #advent-of-code
- #distillery
- #processes
- #api
- #forms
- #hex
- #security
- #metaprogramming
Our Sponsors
Build Elixir applications with speed and confidence.
We build reliable cloud platforms for business-critical systems.
Catch errors, track performance, monitor hosts and more.
Error tracking, logs, uptime, and Just Enough APM. Built for developers.
Elixir, Erlang & BEAM conferences from Code Sync - join us in 2026!
Practical resources that improve the lives of professional developers.
Bringing learning, work and compliance together since 1987.
The deployment platform built for Elixir: PaaS ease, VPS control.
The team behind Membrane, Popcorn, LiveDebugger. Available for hire.
Courses that'll move you from confusion to "Aha, now I get it!"
Showing Posts 1 to 8- Show Best Posts
- Show All (oldest first)
- Show All (newest first)
dimitarvp
Forgive me if I am misunderstanding but wouldn’t the “fallback to Any” part of the Protocol serve you well?
If not, I am not sure protocols have much value, you might as well have a single module with 5+ functions, each of which pattern-matches on its parameter(s) and has 10+ separate pattern-matching heads and implementations. I can see how that can get unwieldy and a bit bigger than we’d be normally comfortable with. So yeah, duck typing as you said.
tcoopman
Unless I read fallback to Any incorrectly, it’s a fallback for the full implementation, not for a single function.
When I try this, I get a ton of warnings that required functions are not implemented.
So no, fallback_to_any is no solution.
That’s not really the reason, the reason is that I want to be able to add extra implementations for test only, so that’s not really an option as well.
dimitarvp
OK, but that’s kinda sorta easy to do with
moxandpatchthough?thiagomajesk
I think what OP wants is “default interface implementations” like in Java or C#. I’m not sure if this will ever be possible in Elixir. I’m not sure but it seems to me this would break the mental model around protocols in the language.
I’d say that if you cannot be strict about it maybe you should go another route. Have you tried using a behaviour with different adapters for this instead of a protocol?
tcoopman
I think switching to behaviours that have optional callbacks is probably a good idea. Thanks for the reminder.
LostKobrakai
I still don’t fully get why you want to implement the protocol expected implementation only on one protocol implementation. I’d expect the reason for that protocol function to exist is so that it is implemented for all protocol implementations.
I’m wondering if you’re working on the wrong level of abstraction somewhere here.
tcoopman
In the end I want to do it fully.
Right now though, it’s 2 related things: 1. I’m experimenting with the design, so only doing it for 1 implementation is a lot easier and 2. I also try to work in small steps. So I was looking for ways of doing it in a small step (first for 1 implementation) and then later the rest.
LostKobrakai
I‘d probably just use a second protocol with just a single implementation for testing until you know what you want to add to the first protocol.