Re:Class Hierarchies? Don't Do That
by dllthomas on Sunday March 30, 2014 @05:23PM
(#7498006)
Sum types only cover this trivially when the type is closed or when those adding new subtypes can be expected to modify all uses of the type. It's still not the same thing.
[ Parent
| on HN ]
The need for an open sum tends to be vanishingly rare in my experience.
It occurs moderately frequently in libraries where a user should be able to define domain specific types along with how the library should treat those types. A classic example would be a raytracer where the user might be adding new kinds of scene elements. It probably shouldn't occur in application code.
For what it's worth, I do think people underestimate the applicability of closed sum types.
I'm aware of the raytracer library example. The solution to that is to not use types to represent shapes. Instead, classify shapes by primitive types (triangles, quads, bezier curves, NURBS, etc.) and use a closed sum for those. It's far less common for a user to want to create a new primitive type and you can always use an escape hatch in the closed sum that allows the user to define their own primitive along with a function to draw it in terms of one of the other primitives.