Woah. Did not realize you can do this. So much more readable than anon functions. Time to go clean up some code 
law
1
augnustin
Bringing the discussion up, as it’s been a while I felt like I was missing something, and I may finally have nailed it.
Context
As far as I understand, the philosophy of a functional programming language is about data transformation.
Hence the pipe operator is amazing in Elixir as it is exactly what it does:
initial_data
|> first_transformation()
|> second_transformation()
|> third_transformation_with_params(my_param)
|> another_one()
# final_data
But there are cases where the transformation should be applied conditionally, which is what is discussed here.
Of course, one can write another sub-method like:
def maybe_apply_second_transformation(data, true), do: second_transformation(data)
def maybe_apply_second_transformation(data, false), do: data
initial_data
|> first_transformation()
|> maybe_apply_second_transformation(should_apply)
|> third_transformation_with_params(my_param)
|> another_one()
But that’s way too much extra code for a simple condition.
So I like @OvermindDL1 quite a lot:
initial_data
|> first_transformation()
|> case do
data when should_apply -> second_transformation(data)
data -> data
end
But this syntax is quite heavy for a simple if, the data -> data line doesn’t bring any valuable information, not perfect IMHO.
Question
Shouldn’t this be valid:
initial_data
|> first_transformation()
|> (if should_apply, do: second_transformation())
|> third_transformation_with_params(my_param)
|> another_one()
I know it doesn’t now, I guess, the data is given as the first parameter of if, instead of should_apply.
But when writing a if in a pipeline, it is more useful to get the data as the first parameter of the do block than of the if condition.
# Not useful
boolean
|> if do: data
# More useful Useful
data
|> if boolean, do: fn d -> d end
# data
If the if operator shouldn’t be used for backward compatibility reasons, shouldn’t we imagine another one, like if_map? Or even a syntax like:
initial_data
|> first_transformation()
|>? should_apply, do: second_transformation()
|> third_transformation_with_params(my_param)
|> another_one()
Thanks for reading and feedback
0
LostKobrakai
I feel that statement is the trap here. Instead of naming it maybe_apply_second_transformation I’d suggest something like prepare_for_third_transformation (maybe inline second_transformation(data)) and then the code is totally fine. Most importantly that code will age the best. Say at some later point you also need to do some different transformation for the false case as well. Just replace data with whatever that other case needs to be applied to.
All your proposed short inline forms will likely no longer be short and sweet once you need to deal with 2 cases and once you’re no longer at 1 or 2 cases you’ll need to switch to the function (or case) version anyways.
0
wolf4earth
As a possible alternative to writing a full fledged maybe_* function, you can also consider to use a general purpose maybe_if/3 function. I’ve done that in the past when I needed to chain multiple optional steps.
initial_data
|> first_transformation()
|> maybe_if(should_apply_step2, &second_transformation/1)
|> maybe_if(should_apply_step3, &third_transformation_with_params(&1, my_param))
|> another_one()
where maybe_if is defined like this:
def maybe_if(data, true, action)
when is_function(action, 1),
do: apply(action, data)
def maybe_if(data, false, _action), do: data
4
augnustin
Thanks for feedback that’s very interesting.
@wolf4earth I like your solution very much, I shall go for it. 
All your proposed short inline forms will likely no longer be short and sweet once you need to deal with 2 cases and once you’re no longer at 1 or 2 cases you’ll need to switch to the function (or case) version anyways.
@LostKobrakai I don’t really agree with your point.
data
|> first_transformation()
|> if should_apply,
do: second_transformation(),
else: alternate_transformation()
|> third_transformation()
reads much clearer IMHO than
data
|> first_transformation()
|> case do
data when should_apply -> second_transformation(data)
data -> alternate_transformation(data)
end
|> third_transformation()
My thinking made me understand that in order to get my ideal version to work, one should write the if/4 macro (from if source code). Apologies I suck at macros… 
defp build_if(nil, condition, do: do_clauses, else: else_clauses) do
build_if(condition, do: do_clauses, else: else_clauses)
end
defp build_if(entry, condition, do: do_clauses, else: else_clauses) do
quote do
if(condition, entry |> unquote(do_clauses), entry |> unquote(else_clauses))
end
end
Though my code may not be correct, couldn’t it work?
The cool thing is that from my understanding, it could be backward compatible, as it is easy to detect that entry is nil, so the very same operator could be used (though it may be confusing at first).
0
LostKobrakai
I’d say so as well, but imo non of that needs to be handled as part of the pipeline. The pipeline should only be concerned with the steps needing to happen, but not with what happens as part of those steps – and doing nothing is a valid option for the latter.
For your examples second_transformation and alternate_transformation are both versions of some_transformation_needed_before_the_third_transformation, which should be what’s piped into.
0
augnustin
I guess I’m not yet comfortable with the expressiveness of idiomatic Elixir code.
Take this SO question.
It seems like the solution in Elixir is to always create more functions, whereas I’m a one-liner fan, as context always varies, and on-the-fly definitions seem more appropriate to me than more code lines.
But this would be a long topic to discuss!
0