Turning case-do up to 11

Questions / Help
1

Hi.

I’m always looking for ways to make code more manageable, readable, and nice to look at. To this end, matching and the case-do statement have become my favorite tools in doing so.

I often found myself writing code like this:

case condition1 do
   match1 -> case condition2 do
               match2 -> ...

I tried pulling out the inner case-do into a function but that wasn’t “pretty” by any standard in a lot of cases. (In some cases it was definitely needed - one size doesn’t fit all.)

What I do these days looks more like this:

case {condition1, condition2} do
  {match1, match2} -> ...
  {match1, _}      -> ...
  {_, match2}      -> ...
  _                -> ...
end

The only thing I don’t like about this is that you have to repeat sometimes the result of one case in another. Just putting it in front of the case statement makes you compute something that might not be needed. You also cannot emulate this:

case condition1 do
   match1 -> common = ...
             case condition2 do
               match2 -> <do something with common>
               match3 -> <do something with common>

So, combining a case-do with tuples is no panacea. But it can clean up some code considerably.

Though you could do this…

common = fn -> <something common> end

case {condition1, condition2} do
  {match1, match2} -> common.() ...
  {match1, match3} -> common.() ...
  {match1, _}      -> ...
  {_, match2}      -> ...
  _                -> ...
end

Hmmm…

Any additional ideas are very welcome!

1 Like
2

Have you tried the with/1 special form?

It is pretty useful to unwrap nested case-expressions.

10 Likes
3

I keep forgetting that construct exists!

Thanks! (Sorry for the late reply… busy busy.)

But does the construct truly do anything but open a new scope?

Like, let’s look at the example in the docs, and rewrite it:

opts = %{width: 10, height: 15}
if true do
  {:ok, width}  = Map.fetch(opts, :width)
  {:ok, height} = Map.fetch(opts, :height)
  {:ok, width * height}
end

I have no elixir environment at this computer, but this should be the equivalent, right? Or did I miss something?

[EDIT: I guess the else block for failed matches is of course awesome.]

Could you please give me an example of how you would rewrite a nested case-do statement so I get a better idea of what you’re aiming at?

4

Your code crashes on a failed match, using with it would “continue” in the else branch.

I can’t give you an example of how to rewrite a nested case, I’m on mobile only until I finished reinstalling my laptop.

5

The biggest use of that I see is that it replicates the clean code you get from using the Maybe monad in Haskell-likes. As long as your functions fail by returning something emulating a Maybe - so basically {:ok, result} and {:error, result} and you use when to compute all the expensive parts, then you can basically reap the benefits of Maybe without implementing a new construct for it.

with {:ok, phase1} <- expensive_computation(),
     {:ok, phase2} <- read_something_from_db(phase1),
     {:ok, phase3} <- do_a_file_operation(phase2) do
  phase3
else
  :error -> :error
end

[EDIT: Fixed the operator as suggested by @Qqwy]

I like that. :slight_smile:

The purpose of a Maybe is to “fall through” a computation when any step fails, without forcing the user to riddle the code with error-handling after every step. I don’t know how efficient with/1 is in regard to going to the else branch but it sure matches the elegance of such code without much effort.

You even get to define your own pattern what constitutes a Maybe. It just needs to be conveniently match-able. The Erlang convention of using :ok and :error tuples is hard to beat in this regard.

So, I’ll definitely take with-do-else into how I write code in the future. Thanks!

1 Like
6

Be warned that with {:ok, result} = something() and with {:ok, result} <- something() mean something different!

With <-, the else will be called when it is not matched (or, if there is no else, the non-matching result is passed on to the outside scope).

With =, a MatchError is raised instead.

1 Like
7

Oh, sorry, those were typos. I meant to use <-.

Thank you.

8

Here’s a good thread on Twitter about designing with flows. On a past episode of ElixirTalk, Chris and @desmond talked about how they use it (forgot which episode.) I’ll likely refactor my few with statements to how @devonestes suggested.