Share via


Req12: Select Case on object identity and type

[This post is part of a series, "wish-list for future versions of VB"]

 

VB already has a powerful "Select Cast" statement, e.g.

        Select Case x

            Case Is = 1

                Console.WriteLine("x is equal to 1")

            Case Is > 7

                Console.WriteLine("x is greater than 7")

            Case 2 To 4

                Console.WriteLine("x is between 2 and 4")

        End Select

 

IDEA: Allow Select Case on object identity. For example,

        Select Case sender

            Case Is TextBox1

                Console.WriteLine("sender was TextBox1")

            Case Is TextBox2

                Console.WriteLine("sender was TextBox2")

        End Select

 

IDEA: Allow Select Case on type. For example,

        Select Case TypeOf(sender)

            Case Is TextBox

                ' Type of "sender" is TextBox inside this block:

                sender.ReadOnly = True

            Case Is Label

                ' Type of "sender" is Label inside this block:

                sender.AutoEllipsis = True

        End Select

This would provide an alternative to the common object-oriented style of writing a "visitor" pattern by overriding the "Visit" method on each subtype. Instead, in the manner of F# and other functional languages, you could gather the visiting code together in one place. Note that you wouldn't be allowed to GOTO from one branch to another (except maybe from a subtype to a supertype!)

 

Provisional evaluation from VB team: This is a decent idea, worth considering against the other decent ideas. (If you have other scenarios, please write in with them!)

Comments

  • Anonymous
    February 14, 2010
    The select case on type is incredibly important, but I'm not so sure about the syntax. Instead of implicitly changing the variable's type, how about renaming it? Something like:   Select value As TypeOf(expression) This way you can switch on an expression, not just a variable. And it makes it clear that the value is changing type. >  Note that you wouldn't be allowed to GOTO from one branch to another I don't see that as a problem. If you are goint to mix goto and select case, you are better off ditching both and using if blocks.

  • Anonymous
    February 14, 2010
    Select Case on type is very useful and I like the idea of providing typed value in Case branch without need to do DirectCast in each branch manually. Usage of original name is not problem for me - it's not change of variable value, it's only knowledge of compiler that in this branch the Object can be treated as TextBox - like in With DirectCast(sender, TextBox)    .Text = ":-)" End With GoTo >> Some compiler warning or error when GoTo ends in different branch (of incompatible type) is useful but not hight priority. Somebody who uses GoTo have to really know what (s)he is doing! In case of incompatible types InvalidCastException may be raised in runtime.

  • Anonymous
    February 15, 2010
    The comment has been removed

  • Anonymous
    February 17, 2010
    I have had multiple instances of these scenarios where this feature would have been useful.

  • Anonymous
    February 17, 2010
    Fix the compiler warning rules for select Case In the following example all the cases are covered. Public Function NZP(ByVal i As Integer) As Integer  Select Case i   Case Is < 0    Return -1   Case Is = 0    Return 0   Case Is > 0    Return 1  End Select End Function To get rid of the warning you need to change the last case Else.

  • Anonymous
    February 17, 2010
    The comment has been removed

  • Anonymous
    February 18, 2010
    It's syntactic sugar, nothing more, since you can already do this kind of thing with an If statement. But who cares; I like syntactic sugar.  It looks like a good idea.

  • Anonymous
    February 24, 2010
    This seems a good idea - I think I've come across situations where I've wanted to use both of these constructs in the past.

  • Anonymous
    March 01, 2010
    Would be a lot neater than the Select Case True    TypeOf() That i end up using for this at the moment.

  • Anonymous
    July 24, 2010
    Yes we want it!!!