Re:Intro To Pattern Matching – Covers C# 9
by seemslegit on Wednesday February 19, 2020 @04:25PM
(#22370255)
That's correct, and exhaustively enumerating derived classes at compile-time is usually a bad design either via RTTI type-switching or pattern matching (which is really just syntactic sugar for the former). It prevents for example having derived types injected at run-time in a plugin setting.
Explicitly matching a subset of well-known derived types otoh is a practical compromise in many cases.
[ Parent
| on HN ]
Re:Intro To Pattern Matching – Covers C# 9
by platz on Wednesday February 19, 2020 @07:00PM
(#22371494)
> enumerating derived classes at compile-time is usually a bad design
Depends on what kinds of guarantees you want. At the extreme, you can make everything in the system late-bound, and then you simply have a dynamic language instead of a static one.
Re:Intro To Pattern Matching – Covers C# 9
by seemslegit on Thursday February 20, 2020 @12:37AM
(#22372951)
> enumerating derived classes at compile-time is usually a bad design
did you deliberately omit the word 'exhaustively' here ?
late-bound != dynamically typed, that's exactly the point - you wish to preserve to the ability to have types loaded at run time without knowing their exact type at compile time while still enjoying strong type guarantees. We can do without run-time loading scenarios at all and still see why this is bad, if one adds a derived class to the code base and then has to address it in a bunch of places rather than have all the new functionality localized to the class then it's a smell