roman
Using a literal parameter to choose between multiple function heads
Hi,
Imagine we have a code like this in a language that doesn’t support functions with multiple heads:
def parse_date(format, value) do
case format do
:iso8601 -> Date.from_iso8601(value)
:american -> value |> String.split("/") |> …
end
end
If we always pass the format as an atom literal, i.e. parse_date(:iso8601, value), this is considered an anti-pattern (https://martinfowler.com/bliki/FlagArgument.html).
In Elixir, however, this is not so clear, because the implementations are more separated and there’s no explicit branching:
def parse_date(:iso8601, value) do
Date.from_iso8601(value)
end
def parse_date(:american, value) do
value |> String.split("/") |> …
end
Do you consider this an anti-pattern in Elixir as well, and we should have differently named functions? Or does this approach fit the general pattern-matching style of Elixir?
Most Liked
LostKobrakai
I’ve looked into the arguments of martin fowler:
Tangled Implementation
This can happen, but given in elixir we usually write different function bodies like he does for two different functions I feel this is is not more of an issue then for his proposed solution.
Deriving the flag
Given we’re not in oop land, somewhere some functions needs to decide for which “flag” to use – only then parse_date is called. So most of the discussion is not applicable to elixir. But I’m with martin that boolean flags are bad. I don’t want to see calls like parse_date(true, date) vs. parse_date(false, date) to differenciate :america | :iso8601. Either use atoms describing the flag or if it’s truely boolean use a keyword list: parse_date(value, time_only: true)
al2o3cr
An initial style note: the first argument position is usually reserved for the “subject” - value here - so that pipes work nicely:
some
|> chain()
|> of_expressions(that: return_a_string_shaped_like_a_date)
|> parse_date(:american)
Whether this is better as |> parse_date(:american) or parse_date_american() depends on usage; is the format always hard-coded or is it driven by data (for instance, from a user preference)?
Another deciding factor might be the implementation: are the two function heads independent, or do they rely on common private functions?
Popular in Questions
Other popular topics
Latest on Elixir Forum
Sponsor Spotlight
Courses that'll move you from confusion to "Aha, now I get it!"
Categories:
Sub Categories:
Forums
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.
Develop your skills with books, videos, and courses.
Producing high quality Elixir screencasts since 2017.
Enabling companies to succeed by building software people love.
Courses that'll move you from confusion to "Aha, now I get it!"