Object literals vs pattern matching or alternatives?

Questions / Help
,
1

Hi! Quick question from a guy coming from Javascript:

Whenever I have to handle some conditional behavior, like ‘do something depending on a well-defined flag’, instead of using a switch/case construct or a bunch of if/else, I usually do something like this:

    const thingDoers = {
        thingOne: () => { /* do thing one */ },
        thingTwo: () => { /* do thing two */ },
        thingThree: () => { /* do thing three */ },
        DEFAULT: () => { /* do default thing */ }
    }

Then I just run thingDoers[flag || 'DEFAULT']() and it works for all cases. If I have to add an additional one, is just a matter of declaring a new function, no extra logic involved.

Is this an acceptable/common pattern in Elixir as well, or do we just pattern-match the thing? Is there a better / more idiosyncratic way of doing the same?

2

Definitely pattern match.

This is a nice use of multi-head functions AFAIC:

def thing_do(:thing_one), do: # ...
def thing_do(:thing_two), do: # ...
def thing_do(:thing_three), do: # ...
def thing_do(_), do: # ...

thing_do(flag) # If `flag` is `nil` it'll hit the last (default) case

You can do the same thing with one function head and a case if you want. It’s the same thing at the end of the day.

4 Likes
3

Thanks! Looks even cleaner (my main driver for rejecting switch/case and nested ifs)

I’m still learning about Elixir but I’m loving it every day a little more

2 Likes
4

Definitely don’t shy away from case! It’s very commonly used in Elixir. It’s much different than JS’s switch since it deals exclusively with pattern matches (and of course doesn’t need to break).

2 Likes
5

Just adding that your fall-through clause should probably be def thing_do(nil), do: # ... otherwise you could run into some subtle bugs. Since _ will match anything, thing_do(:thang_tree), for example, will successfully hit the default clause. You probably want things to just blow up in that case.

1 Like
6

Thanks for the input! That’s a subtle difference, yes, worthy of consideration.
In my particular case, I guess I’d usually just use _ because I’d want to catch all other cases and send them to a virtual black hole. In an express controller, for example, I do something like DEFAULT: () => res.json({success: false, code: 'UNKNOWN_PARAM'}) (just ignore the fact I’m supposed to check beforehand my flags, it’s just an example)
But I see the value in treating nil as a different thing too

1 Like
7

Yep, I didn’t mean to say you must do it, just consider it :slight_smile: I have a general problem with wording on this site (and in general) :sweat_smile:

8

Yeah, don’t worry! English is not my native language so I understand when people say they have a problem with words lol. Sometimes I can’t brain either.

1 Like
9

Unfortunately it is my first language :sweat_smile:

In any event, welcome to Elixir Forums!

2 Likes
10

I’d question the wisdom of pattern matching on nothing but an atom. Seems like unnecessary polymorphism to me. It would had made more sense if there is a tagged record, ie: {:thing_one, some_data}. Just an atom? Where does it come from?

11

Interesting. I don’t know OP’s exact usecase, though I’ve worked on code matching on atoms before. In that case it was mapping well-known atoms to modules. It was basically just a map but using a function to get around compile-conflicts. The atoms came from database strings (I did not design that code and wasn’t there very long, lol). In this case, OP seems to essentially want a map with executable keys, so I think this is ok? If we’re talking about message passing then ya, a single atom probably isn’t very useful. But ya, there might be an even better solution for what OP is after, I just didn’t dig as I didn’t feel up to XY’ing today :upside_down_face:

12

I was just nitpicking. My point is: if you can get away with hard coding, it would be both easier to read and faster to execute than polymorphism.

1 Like
13

I’m not experienced enough in Elixir to talk about what is necessary or not, but I can answer your question.
In the particular example of my post, I am pattern-matching a single word, which you can totally represent as an atom. It comes from a request. It’s an internal constant that the client knows about, and it’s asking us (the backend) for information about that particular thing.
So for example, I receive { code: 'ABC_123, moreStuff: {...}}, and it’s that constant code that I have to pattern-match (or in JS, do some stuff like my first example)

Would you do it differently? What is the downside of doing ‘too much’ polymorphism? And how much would be too much?

Sorry for all the questions lol but you piqued my curiosity

EDIT: This is just one example, but it’s a pattern I frequently use, to avoid endless conditional statements. If you’ve worked on nodejs in a big-ish project made by someone else, you probably know the pain. We had parsers hundreds of lines long of nothing but endless nested conditionals, until I rewrote them in a functional, composable fashion

14

It seems like you want to first destructure, then parse a string constant into an atom, then dispatch based on the atom, while you can do all 3 in one pattern matching with Elixir on the whole { code: 'ABC_123, moreStuff: {...}} input, which I assume is a JSON string.

1 Like
15

Right, that is what I have to do in JS, in Elixir I can just pattern-match. That was my question. Thanks everyone for your replies! Very insightful, I learned a lot

16

Can you post your final code?

17

Oh sorry, it was more like a theoretical question. I’m learning Elixir and while I do, I usually think about how I would reimplement my existing codebase in an idiosyncratic way on Elixir.

So remembering syntax off the top of my head (sorry for any mistake), it’d be like this:

def do_thing %{:thing_one, payload} do: thing_one_handler payload
def do_thing %{:thing_two, payload} do: thing_two_handler payload
def do_thing %{:thing_three, payload} do: thing_three_handler payload
def do_thing _ do: default_handler