Primitive Confusion
My last post on primitive obsession has been a while ago, whose predecessor is even older.
Primitives are still bad. The following illustrative code just happened to me two days ago (it didn’t reach production, but hey):
See the problem? Because we are the dealing with ids as strings, the compiler can’t help us when we use APIs the wrong way. When you use the API correctly in unit tests it so can happen that confusing such IDs may only turn up in integration or, as the very last resort, production.
The same mistake can happen to us in other languages, too. Here’s the example in F#:
The compiler happily does its job, no surprises. Obviously I chose F# as second example for a reason. Here, the barrier to type even singular primitives to provide improved compile time safety is considerably lower. Enter Discriminated Unions.
They are something like the crack of type-safe pattern matching, or state representations on steroids or whatever you like to call them. Let’s use them in our example:
In this case the userId
and productId
are still essentially strings, but you can only get at them by acknowledging the type that is guarding those primitive values. It is hard to conceive and even smaller encoding of semantics with regard to some primitive value, which is why I highly approve of this use case of discriminated unions and often miss them in C#.