So this is just a Hail Mary to try to fit data into a struct? If so i’m not the biggest fan. It reminds me a whole lot of HashWithIndifferentAccess, which, personally, has caused a ungodly amount of pain. I’ve found that if you need to reach for tools like this, you have a structural issues lurking somewhere.
Not exactly. The main use case for this library is taking data from outside the app, converting it into structs as quickly and painlessly as possible, and then using structs throughout the rest of the program. Commonly, this would involve writing really dumb stub code for each of your structs:
def new(input_map) do
# ... etc
This is pure shitwork, and gives the programmer the chance to mistype too many things.
The alternative to this approach is passing around the raw input data (probably a map with string keys) and using that directly. I talk about why this approach is less attractive than “structs-ASAP” in my previous post.
So rather than a crutch like HashWithIndifferentAccess, in which every subsequent handler of the data is receiving a poisoned data structure, ExConstructor is there to sanitize and properly convert external input ASAP, then use well-specified structs everywhere else.
What is the big deal about snake case vs camelcase here, exactly?
Sometimes externally sourced data uses convention opposite of that used in the rest of your code; for instance, many JS-backed APIs use camelCase by convention, whereas Elixir is predominantly a snake_case community.
Rather than forcing the developer to implement the conversion manually (in a bone-stupid stub method, as I illustrated elsewhere on this page), ExConstructor gets performs the conversions itself and lets the programmer work with a more consistent format.