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.
derek-zhou
Gonza
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
0
derek-zhou
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
Gonza
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
0
dimitarvp
Gonza
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
0