VB 10 thoughts (part 3)

Posted Sat, Oct 6 2007 12:54 by bill

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


  2. 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.

  3. 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)



     
Filed under: , ,

Comments

# re: VB 10 thoughts (part 3)

Sunday, October 07, 2007 11:16 PM by Jonathan Allen

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

# re: VB 10 thoughts (part 3)

Monday, October 08, 2007 12:41 PM by Bob Bingham

How about "Persistant"?  Or is that Persistent?  Oh well, the IDE will type it out for us bad spellers. ;)

# re: VB 10 thoughts (part 3)

Monday, October 08, 2007 7:03 PM by bill

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.

# re: VB 10 thoughts (part 3)

Thursday, October 11, 2007 7:14 PM by Paul Vick

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

   Bar

End Enum

<System.ComponentModel.DefaultValue(Foo.Bar)> _

Class Baz

End Class

Are there other cases?

# re: VB 10 thoughts (part 3)

Thursday, October 11, 2007 7:50 PM by bill

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 <g>.

Here's some sample code :

Public Class UserControl1

  Private m_FooProp As Foo = Foo.Baz

  <System.ComponentModel.DefaultValue(Foo.Baz)> _

  Public Property FooProp() As Foo

     Get

        Return m_FooProp

     End Get

     Set(ByVal value As Foo)

        m_FooProp = value

     End Set

  End Property

End Class

Public Enum Foo

  Bar

  Baz

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:

<System.ComponentModel.DefaultValue(GetType(Foo), "1")> _

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)