3 ms·
It would require some type checking and casting (or runtime exceptions) but wouldn't the C# equivalent to the F# approach be abstract class User, class ActiveUs
by deanCommie 11y ago
It would require some type checking and casting (or runtime exceptions) but wouldn't the C# equivalent to the F# approach be abstract class User, class ActiveUser : User, and class DeletedUser : User
- drabiega 11y agoI believe this is what the author is referring to at the end: >Unfortunately, the lack of discriminated unions and pattern matching makes the F#’s approach mostly unbearable to implement in C#. It’s possible in some simple cases but still remains pretty tedious.
- inglor 11y agoGood point. No, I don't believe that's what they mean there. The OP defines the F# version user as a union of either an activeuser or a deleteduser. The C# idiomatic way would be to use an abstract class and implement two subclasses. The difference is that in the C# way someone could in theory (if they're your evil wizard arch nemesis for example) create a third user subclass and harm the type soundness. In practice you can guard against that as well if you really have to guard against evil wizards.
- pionar 11y agoThe article is pointing out (I think) that since C# and F# are such different paradigms, they have different best practices for handling invalid states. F# has these best practices built in to its type system. The way the author is coding the domain models, there's no way for the model to be in an invalid state. C#, on the other hand, does not give this safety in its type system (and doesn't make it easy to "abuse" the type system to provide it). One can use contracts[0] to do this, but it provides mainly runtime checking, not compile-time checking like F#. [0]http://www.dotnetcurry.com/csharp/1172/code-contracts-csharp-static-runtime-checks http://www.dotnetcurry.com/csharp/1172/code-contracts-csharp...