It’s not, I love with, I just wish it was better, and thankfully elixir is extensible via macros(and I kinda like Zig’s try). I’d love if we didn’t have to wait for those changes to land in the languages themselves or to be added in a library by someone with an important name.
In the context of the OP I think it’s valuable because, well, having a normalized return type is valuable but it has the same side effect as with: it makes you create functions
I have a problem personally with that because there wasn’t a case where this sequence doesn’t happen:
- A few lines of code exist, and they’re extracted to a private function to make
withless painful or avoid credo’s cyclomatic complexity check, or the formatter butchers the code, orwithwould only handle sparse branching points and you need many nestedcases and Credo gets mad at you, or some other “small” issue - Now that the private function exist, that piece of code can be called by other code in the same module
- 2 or more functions that use those private functions have slightly different use cases, so they start to add
optsto it to change the behavior - These functions get used by even more functions ouside the module, which also have different requirements
- On top of the many slightly changes in required behavior, they also produce side effects, so now you need to keep track of that too
Functions have the side effect of encouraging reuse and that reuse is rarely intentional enough to not cause problems
So while, again, I value value normalization, I don’t think libraries like the OP help a lot in the long term. I have similar gripes with Ecto.Multi vs Repo.transact like in the other thread. The common suggestion of “create more functions”(and maybe pipe them) sounds good on paper but it almost always gives me problems and I don’t want all that.
