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?
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?
the first argument position is usually reserved for the “subject” - value here - so that pipes work nicely
That’s a very good point. I think it alone is enough to avoid this style.
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)?
The format is always hard-coded, that’s a key part of the question.
are the two function heads independent, or do they rely on common private functions?
Could you expand on that? I didn’t see it as a relevant factor.
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)
Here’s an example of “two heads” with overlapping implementation:
The heads here are matching on an atom (Calendar.ISO) inside the input struct, and the second one depends directly on the first. Making them separate functions would obscure that coupling.
The function called to do the work, Calendar.ISO.date_to_string is another example of this style:
date_to_string is only responsible for type guards and delegates its work to a helper function. Passing the format as an argument instead of having date_to_string_basic and date_to_string_extended helps here, because the decision about which format to use (in the code calling to_iso8601) is several layers of function calls away from where the code branches (date_to_string_guarded's two heads).