← Back to Upcase

Domain Specific Types in Elm


(Upcase ) #1

Compilers are powerful helpers but they can only do so much with primitives. Joël and Stephanie fix a bug by introducing domain-specific types. Learn about how these encode real-world context, what are the downsides, and how some functional programming concepts can make those downsides go away.


This is a companion discussion topic for the original entry at https://thoughtbot.com/upcase/videos/domain-specific-types-in-elm

(Kurt Mueller) #2

Informative presentation. I like the convenience functions at the end like Dollar.sum that seem to hide away the map function. Should map, map2, and map3 be used internally inside a module but not exposed as part of the module’s api?


(Joel Quenneville) #3

I think that’s up to you. If you’re publishing a package you should probably expose the various map functions so that people can do arbitrary things with n dollar values.

If it’s internal to your own project, then I suppose anytime you wanted to do something new you could define a new function on the Dollar module yourself. You might possibly want to use the map functions to do a one-off thing with a lambda somewhere but I’d expect most common operations to end up defined in the Dollar module.