The specific bug is that by spreading your type logic all over the program, if you need to update it, you need to find all those if statements to update them. So your code is more error prone and less maintainable. Its also a violation of the DRY principle. Specifically if you want to add a new type, and forget to update one of your many if statements you'll have a bug. Or if you want to change the behavior of a type, and forget to update it in one of the many if statements.
I did mention "OO era" in case because I new the functional style would be mentioned. Note however that with a functional style, you shouldn't throw away encapsulation necessarily. Encapsulation is modeled in your code module. You could do the exact same thing in a functional style without proliferating your code with if statements.
The functional equivalent for this is multimethods. (though I'm not sure the language you are using supports that construct)
You might be missing the point when you say this. Based off what you said, I feel that I might not have explained myself well:
The specific bug is that by spreading your type logic all over the program, if you need to update it, you need to find all those if statements to update them.
I’d like to clarify that the assertNever function tells me if a new type was added and it tells me if one was removed.
So I don’t need to “find those if statements” because the compiler will inform me.
But no, the compiler won't tell you. An exception will tell you at runtime. Assuming you tested correctly you may find this before it hits production. But its hard to argue that this is better than just using better coding practices.
if/elseif/... is a code smell. A bad practice if it can be avoided. In this case it can be avoided.
The specific bug is that by spreading your type logic all over the program, if you need to update it, you need to find all those if statements to update them. So your code is more error prone and less maintainable. Its also a violation of the DRY principle. Specifically if you want to add a new type, and forget to update one of your many if statements you'll have a bug. Or if you want to change the behavior of a type, and forget to update it in one of the many if statements.
I did mention "OO era" in case because I new the functional style would be mentioned. Note however that with a functional style, you shouldn't throw away encapsulation necessarily. Encapsulation is modeled in your code module. You could do the exact same thing in a functional style without proliferating your code with if statements.
The functional equivalent for this is multimethods. (though I'm not sure the language you are using supports that construct)
See clojure.org/reference/multimethods for example
You might be missing the point when you say this.Based off what you said, I feel that I might not have explained myself well:I’d like to clarify that the assertNever function tells me if a new type was added and it tells me if one was removed.
So I don’t need to “find those if statements” because the compiler will inform me.
That is a work around.
But no, the compiler won't tell you. An exception will tell you at runtime. Assuming you tested correctly you may find this before it hits production. But its hard to argue that this is better than just using better coding practices.
if/elseif/... is a code smell. A bad practice if it can be avoided. In this case it can be avoided.
Try compiling this code. The compiler will in fact tell you if you’re missing a case that’s described in the discriminated union.
Of course, that only works if you recompile all your libraries and dependencies. The OO solution would work even if you only recompiled the class.