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.
Because in any non-trivial situation, this makes the function difficult to use and and forces its callers to change every time the internals of that function change.
When creating a user, I really just want to pass in the relevant data for that user. I don’t want to also know that this action needs to make three HTTP requests and provide the credentials for those in every place that creates a user. Then a new requirement comes in saying that we also need to send an email and suddenly, every place that creates a user has to be updated to know about a mailer.
Without some mechanism to handle default dependency configuration, we always make a trade-off. Every time a dependency is pushed upwards, the code becomes more isolated at the cost of being more difficult to use.
…which is once a year. You are exaggerating a problem that’s almost never there.
That’s why you have wrappers. They can have the extraneous function arguments memorized via module attributes and/or runtime configuration.
It can and it does happen, and there are ways around it like pointed out above. I appreciate code with dependencies exposed because it allows me to mock it easier when I have to.
I wish I could live in a world where requirements change significantly once a year instead of twice a week 
Definitely agreed about the rest, though 
Thank you! I kept seeing people talking about DI in this thread and another and kept thinking I was missing something.
Ehn, “constructor” is a legit FP term 
I do hate when people say “method” though, mostly because I feel that deep down they really do believe they are somehow still methods 
Near the end of my time with OO, I started feeling getters and setters were pretty pointless, feeling like a holdover over for when code like this was acceptable:
user = new User
user.set_name("Bender Bending Rodríguez")
user.set_email("bender@planetexpress.com")
Maybe it still is? I dunno. But I view it as a giant smell if method names prefixed with get_ and set_ doing anything or than returning the raw property value. It’s just plain confusing. If you do this, you not longer have a “getter” or “setter” and the method name should reflect this.
In terms of renames, I’ve never been in a situation where renaming a field didn’t result in a project-wide rename. I haven’t worked on any truly massive projects before (biggest was ~1 million lines of Ruby) and of course it would be different for an app vs a library. I have heard someone on this forum lament not being able to change the name of a field in their library, but there are still other ways to deal with the mismatch (which I believe have been alluded to already?)
So many other thoughts on this thread but I’ll leave it at that!
© Copyright Elixir Forum | Terms | Privacy & Cookies
