This is a valid use case for “setters”. Sometimes a struct contains complex data structures and in order to expose a simple API, it’s convenient to use a “setter”.
krasenyp
Sorc96
Hopefully this doesn’t come off too negative, I’m just poking some fun.
Something I’ve noticed about functional programming communities is that you absolutely have to use the correct terms. Talking about getters and setters will just get people mad because you don’t need that stupid overengineered OOP nonsense. Call them lenses and suddenly you’re an intellectual who understands the value of hiding the exact shape of the data.
I have yet to find an acceptable term for dependency injection, which is by far the thing I miss the most in functional languages.
That being said, defining functions for accessing simple struct keys is far from being idiomatic in Elixir, so you’re almost certainly better off not doing that and instead treating the shape of the data as your “interface” and pattern matching on it.
You can of course pre-calculate more fields based on existing ones when creating the struct, sou you could keep backwards compatibility this way if the internal representation needs to change. Of course, this only works as long as the rest of the code isn’t creating your struct directly, but rather through your own function that calculates the other fields. But don’t dare call this a constructor, we don’t do that here (/s).
0
D4no0
Can you show an actual example (even with code that doesn’t work) where dependency injection would be useful? I have used in kotlin and I still can’t shake the fact that it covers flaws related to classes, I can’t see an actual use-case where it would be useful to have them in elixir.
0
dimitarvp
Okay, then use Elixir idioms – no getters or setters unless you need logic at places (classic example: get_full_name that combines first and last names). That makes it pretty maintainable as you don’t use superfluous layers of abstraction.
And then there’s me who never got mad but still cringes at both. (Though lenses are still the better descriptive term IMO.)
0
Sorc96
Every week or so, there is a new thread asking about testing some kind of an external side effect. Inevitably, people recommend five different mocking libraries, each with its own set of drawbacks, and everyone says that their particular use case doesn’t work with at least three of those.
This obviously seems way more complicated than it should be, but what’s worse, it ignores hard earned knowledge about good testing practices. Mocking something that happens ten layers deep in the code that is being tested, always results in tests that know too much, and therefore break too easily.
0
dimitarvp
How would you solve this in Elixir if you were all-powerful and could do anything at the snap of a finger?
0
Sorc96
I don’t think it’s really possible, which is probably why there isn’t a great solution. I would either pass dependencies explicitly, or set them up in config and hope I will never need more than one setting per environment. That’s often good enough. Until it isn’t.
0
dimitarvp
Well, if we had perfect solutions to every problem, this and every other programming forum would no longer exist as programming would be now a 100% solved problem. 
IMO the FP approach to all this is great because it makes you think really hard about dependencies, and uncoupling them, and/or making those dependencies configurable.
This still nets you bigger clarity of yours and others’ (that you depend on) code. Some say “needless information about how stuff works below” but to me it’s helpful to lift a mythical veil and have a better understanding.
0
krasenyp
Speaking of dependency injection, in FP it’s called an argument to a function. I really don’t understand why most people writing Elixir just don’t like passing dependencies via function arguments. If you don’t state what your logic depends on, it depends on everything and it’s almost impossible to isolate and test.
4
dimitarvp
People still believe global mutable state is a good idea (dependencies in configs can and do work alright in Elixir, though they do have limitations as people very quickly discover when they need to mock e.g. DateTime).
Which is a maturity point in the programming career. It’s impossible to just tell somebody “don’t do that, it will lead to problems”. They have to see and suffer the problems to believe it.
1