Crowdhailer
Should libraries implement default callbacks that are intended to always be overwritten?
My opinion very much undecided on this Question so all comments welcome.
This is probably best discussed using the concrete example I am considering at the moment in Raxx.
(Raxx has the goal of being a capable toolkit for developing lean web applications in Elixir.)
For simple endpoints applications implement the Raxx.SimpleServer behaviour.
Simple endpoints are when streaming is not required for either request or response, if streaming is required then the Raxx.Server behaviour is implemented
A simple example would look like the following.
defmodule MyServer do
use Raxx.SimpleServer
@impl Raxx.SimpleServer
def handle_request(%{method: :GET, path: []}, _state) do
response(:ok)
|> set_header("content-type", "text/plain")
|> set_body("Hello, World!")
end
end
The line use Raxx.SimpleServer defined a default implementation of handle_request/2 which any application is always expected to overwrite.
The default implementation shows a page that explains what a user should be implementing, and this is done to help users.
https://github.com/CrowdHailer/raxx/blob/master/lib/raxx/simple_server.ex#L105-L111
I am no revisiting this choice for the following reasons.
- behaviours create a compile time warning when one of their callbacks is not implemented,
this is lost by implementing a default. Any mistakes are found only at runtime, hopefully by tests. - Safely generating this page required adding a dependency on eex_html, this dependency is included only to render pages that should never be rendered in a correctly set up application
- These helper pages are useless if the client is not a human. i.e. when making api services.
In summary I am thinking of removing this default because a compile time warning is more useful than any information that might be show at runtime in the page, and in any case is just a copy of the information available in the documentation
Most Liked
josevalim
FWIW, we have been slowly migrating away from default implementations and using optional callbacks instead. If the user wants warnings, then @impl is the way to go. There is an old discussion about it here: Behaviours, defoverridable and implementations
OvermindDL1
What phoenix does in such cases (like router callbacks into controllers and so forth) is it has a ‘jump’ function (action I think?) that is what actually calls the appropriate method, and if it throws, like it doesn’t exist, then it reports it as such. This means you don’t get compile warnings though as it’s an apply, however with macro work to ‘bake in’ the calls without using apply you could get the best of both worlds? It would require making a pre-call function in that same module and calling that instead, and having it call the real function that needs to be overridden. That would give both a warning, maybe even an error at compile-time, but if such a thing does somehow make it through then it would give a good message.
On the other hand, making a public function with a (mostly) uncallable name that just calls the functions that needs to be implemented locally then it wouldn’t compile if they didn’t exist, but you’d need to craft good default data to let dialyzer handle it properly and that can be pretty hard to do without taking ‘opaque’ arguments in (this function would never actually be called, it’s sole purpose is just to require those functions).
Although at that point you could just analyze the module info(:functions) at compile time from the thing that calls those implementations and verify they exist first, but that would involve requiring those files to be compiled first and the beam files to be scanned.
Honestly, I’d say just implement a behaviour, no default implementations, and let the compiler handle it as normal. 
LostKobrakai
If you want to have a descriptive error page I feel it’s in the same realm as the phoenix error page with the debugging information: Enable it in :dev, but fail for other environments.
Popular in Discussions
Other popular topics
Latest on Elixir Forum
Sponsor Spotlight
Phoenix, LiveView, multimedia pipelines, distributed systems. 400 engineers, Elixir since 2017. Available for hire.
Categories:
Sub Categories:
Forums
Popular Tags
- #ecto
- #liveview
- #troubleshooting
- #learning-elixir
- #deployment
- #library
- #erlang
- #testing
- #genserver
- #mix
- #absinthe
- #remote-other
- #otp
- #plug
- #how-to-question
- #macros
- #postgres
- #channels
- #elixirconf
- #exunit
- #discussion
- #code-sync
- #javascript
- #podcasts
- #onsite
- #dialyzer
- #docker
- #authentication
- #umbrella
- #full-time-contract
- #podcasts-by-brainlid
- #ecto-query
- #elixir-ls
- #phoenix_html
- #iex
- #blog-post
- #graphql
- #genstage
- #ai
- #websockets
- #supervisor
- #advent-of-code
- #elixirconf-us
- #distillery
- #processes
- #forms
- #api
- #metaprogramming
- #security
- #performance
Our Sponsors
Build Elixir applications with speed and confidence.
Supporting innovation across the BEAM ecosystem.
We build reliable cloud platforms for business-critical systems.
Catch errors, track performance, monitor hosts and more.
Error tracking for Elixir devs who love to ship. Start your free account.
Develop your skills with books, videos, and courses.
Producing high quality Elixir screencasts since 2017.
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!"