Yan Cui
I help clients go faster for less using serverless technologies.
This article is brought to you by
Don’t reinvent the patterns. Catalyst gives you consistent APIs for messaging, data, and workflow with key microservice patterns like circuit-breakers and retries for free.
One of the problems with using F#’s Discriminated Unions is that they are not extensible, in that all your union cases must be specified inside one Discriminated Union (abbreviated to DU from this point) type and you can’t inherit from an existing DU type to add additional union cases.
In most cases, having to specify all your union cases inside one DU type makes perfect sense and I’m sure there is a very good reason for the language designers to not allow inheritance with DU types.
However, sometimes I do find myself wishing for some extensibility so that I can keep using DU types instead of having to revert back to a complex class hierarchy.
Suppose you have a messaging application, you can define the different types of messages your system understands as a DU:
However, as the application grows you might want to add more specialized types of messages, and you don’t want to add them to MessageTypes to stop it from becoming bloated and to keep the specialized message types closer to code that actually understand them.
So what do you do in that case? Go back to using a class hierarchy? Sure, that’s one approach.
Another approach to this problem is to use marker interfaces, so the above code becomes:
The fact that DU types can implement interfaces is often overlooked but you can make good use of it here to enable some extensibility to your DU types.
Notice how the function f is changed from pattern matching the union cases to pattern matching against the type of the message (similar to how you can use pattern matching in a try-with block) before passing the massage to the appropriate handler function that understands that specific type.
Well, thank you for reading and hope this post proves to be helpful to you 
Whenever you’re ready, here are 3 ways I can help you:
- Production-Ready Serverless: Join 20+ AWS Heroes & Community Builders and 1000+ other students in levelling up your serverless game. This is your one-stop shop for quickly levelling up your serverless skills.
- I help clients launch product ideas, improve their development processes and upskill their teams. If you’d like to work together, then let’s get in touch.
- Join my community on Discord, ask questions, and join the discussion on all things AWS and Serverless.
This is a cool way to go about it.
I was thinking though, if you had the interface implement the matching function you’d never need to worry about inventing a mechanism for replacing g with f. Even better, you’d never need to write f, only h.
This is a known problem (extensibility or types = more or less what OO provides) VS (extensibility of functions = more or less FP with DU)
There is a lecture on Channel9 nicely explaining the problem and the solution Haskell provides: http://channel9.msdn.com/Shows/Going+Deep/C9-Lectures-Dr-Ralf-Laemmel-Advanced-Functional-Programming-The-Expression-Problem
enjoy.
@Carsten – excellent video, very educational! Thanks for the link.
Pingback: Here Be Monsters – Message broker that links all things | theburningmonk.com
Images on this post have gone missing :-(
thanks, should be fixed now