This project is read-only.

Select statement with Type case clauses

Topics: VB Language Design
Apr 16, 2014 at 8:56 AM
I'm worried about the future of VB.NET. I saw the new language features for VB.NET in a video from the Build conference on Channel9 (
Using Select statements with type checks instead of polymorphism is completely against clean code and maintainability. This feature drives the developers to the wrong way when writing code.
Writing WriteLine(shape.Area) instead of a huge select statement is a much better solution in every aspect.
Apr 17, 2014 at 12:59 AM
madst wrote:
Thanks for your comment! I agree with you that using virtual methods is the ideal object-oriented way of tailoring behavior of a given function to the type it is acting upon. There is a fundamental dilemma, however, that characterizes the main schism between object-oriented and functional styles of programming:

If you want an open-ended set of types with a closed set of functions, object-oriented programming is great: You have a base class (or interface) with a fixed set of virtual methods, and new derived types can always be added, which contribute their own implementation of this fixed set of methods without need for modification to the existing code.

However, if you want to add new functions, you cannot do so without modifying every type in your hierarchy to include a new virtual method and all its implementations. This is often impractical or even impossible.

Functional programming takes pretty much the opposite approach. They have fixed “type hierarchies” in the form of algebraic types, declaring in one central place all possible shapes of a given type. Then they write functions over them which switch on the shape of the type. Because the number of shapes is fixed, a function can provide a complete implementation with a case for each possible shape. You can add as many new functions as you like without modifying existing code; the functions are self-contained.

However, if you want to add a new shape, you’re in trouble. You have to modify the central type declaration, as well as all existing functions, in order to deal with the new shape.

So that’s the fundamental dilemma: Either it’s easy to add shapes/types and hard to add functions, or it’s the other way around. If all languages were pure, this would be a fundamental choice of which language to use. Some languages (Scala, F#), are more multi-paradigmatic, trying to give both styles a fair treatment. The choice is now per “family of types”, and you can have both styles in the same program. However, they are still hard to mix for a given “type hierarchy”.

Type switching in VB is a more modest approach. It is a “poor man’s” version of the functional type match, where object-oriented type hierarchies are “abused” by switching “from the outside”. This lets you add a new shape-dependent function without modifying the hierarchy. Of course there are some limitations to this approach:
  • With the function accessing the objects from the outside, it cannot break encapsulation and depend on private data
  • Since type hierarchies are open-ended, there is no guarantee that such a type switch deals with every case. There’s a type of bug you can have where you forget to deal with a type you’ve added.
Despite its limitations, type switching can come in really handy. I think the limitations will help ensure that people only use it when the better approach – virtual methods – is not available to them. We cannot take a purist stance on this; we need to be pragmatic and give developers some flexibility in how they deal with real-world situations, including being stuck with non-optimal architectures.

Make sense?

Thanks again,

Marked as answer by lwischik on 4/28/2014 at 8:34 PM
Apr 18, 2014 at 11:50 PM
Hi Mads,

Thanks your detailed explanation, it makes much more sense now!
I think I forget to think about the functional style of programming (even Uncle Bob mentioned it in his book), too much OO nowadays :)

Best wishes,