VB 10 thoughts (part 3)

More language thoughts for VB10 (see part1 and part2 for earlier posts)

  1. Delegate combining and removing syntax
    Today in VB if you write a Custom Event handler, you have to write some really long winded code to combine and remove delegates, such as :

    Custom Event Click As EventHandler
       AddHandler(ByVal value As EventHandler)
          m_ClickEventHandler = DirectCast([Delegate].Combine(m_ClickEventHandler, value), EventHandler)
       End AddHandler
  2.    RemoveHandler(ByVal value As EventHandler)
          m_ClickEventHandler = DirectCast([Delegate].Remove(m_ClickEventHandler, value), EventHandler)
       End RemoveHandler

    This really should be simple such as :

    Custom Event Click As EventHandler
       AddHandler(ByVal value As EventHandler)
          m_ClickEventHandler += value
       End AddHandler

       RemoveHandler(ByVal value As EventHandler)
          m_ClickEventHandler -= value
       End RemoveHandler

  3. CObj allowed in Attributes
    If you write a control or component that has a design time value that is an Enum, using the Systme.ComponentModel.DefaultValueAttribute on that property is a pain in VB. The DefaultValueAttribute has overloaded constructors for most of the intrinsic types, one for Object, and one where you specify the type and the value as a string. In C# you get to use the one that takes an object, allowing you to specify an enum value, and it works.  In VB you have to use the one that takes a type and a string containing the value.. that’s a real pain and any breaking changes in the Enum don’t show up at compile time because it’s a string. We should be allowed to use CObj on constant expressions in attributes.
  4. Static versus Shared
    No, I’m not talking VB versus C#.  VB actually has this correct whereas C#’s “static” is misleading, after all the value can change, so that’s hardly “static” <g> What I am referring to is Static variables in VB.  They are seldom used, and seldom understood. And the naming is inconsistent.  It should be Shared, not static, as the variable is Shared amongst calls to that method. So just as Shard is used at class level, it is used at procedure level.
    What I’d like to see is “Static” become obsolete and replaced with Shared. “static would still work, but a warning would be raised. And in the IDE is you typed static, it would replaced it with Shared for you (both at class level and procedure)


5 Comments so far

  1.   Jonathan Allen on October 7th, 2007          

    I have to disagree with you on item 3. I think “Shared” would be misleading because they are instance variables, not class-wide variables.

  2.   Bob Bingham on October 8th, 2007          

    How about “Persistant”? Or is that Persistent? Oh well, the IDE will type it out for us bad spellers. 😉

  3.   bill on October 8th, 2007          

    Jonathan, they aren’t necessarily instance variables. If you use Static in a Shared method it is Shared across all instances. So the lifetime (instance versus non instance) is controlled by the surrounding block.
    But back to the main issue: people do find “static” confusing. The only sense of the terminology is to mean the same as Shared does in VB. As Bob put it, the variable is persistant. That is it is “Shared”. If the method is an instance method the variable is shared amongst all calls to the method from that instance; if the method is Shared, then the variable is Shared amongst all calls to that method from all instances.

  4.   Paul Vick on October 11th, 2007          

    On #13, we still don’t allow CObj, but I believe we did fix the enum problem (I think it had to do with weird overloading rules and conversions). The following code compiles fine:

    Enum Foo
    End Enum

    Class Baz

    End Class

    Are there other cases?

  5.   bill on October 11th, 2007          

    Hi Paul,

    The problem with DefaultValue attribute is if you pass it an enum it compiles using the DefaultValue(Integer) constructor. As such winforms doesn’t recognize the default value *properly*. The bug is more o nthe winforms side of things, but being able to CObj in the attribute would address this; that is the language features would let us work around bugs in frameworks .

    Here’s some sample code :

    Public Class UserControl1

    Private m_FooProp As Foo = Foo.Baz

    Public Property FooProp() As Foo
    Return m_FooProp
    End Get
    Set(ByVal value As Foo)
    m_FooProp = value
    End Set
    End Property

    End Class

    Public Enum Foo
    End Enum

    Note that when you reset the value on the winforms designer the value is still written in the initialize component section. To get it to work correctly you need to use this overload:


    Note how the integer value had to be presented as a string. In C# the original code works because they compile it to DefaultValue(Object) instead of DefaultValue(Integer)