VB 10 thoughts (part 8)

Posted Fri, Oct 12 2007 13:47 by bill

Today I was only going to add one, item, #29, but in writing the samples for it two more items came to mind. One however was an IDE thing more than a language thing, so just 2 items for the list today :)

 

29. Embrace declarative style coding

VB led the way with declarative coding in .Net with declarative events and interface mapping. LINQ, WPF and WCF all encourage us to move towards declarative style coding, and this is a good thing. But today many of the common patterns we use are still implemented imperatively rather than declaratively.

For example, a bit over 3 years ago I blogged about Custom Events in VB, and how I thought it missed the mark because all we got was low level nuts and bolts to then write our own imperative code.  What I suggested at the time was look at the reasons people use custom events and from there provide simple to use declarative style syntax. Have a read of that blog entry to see what I mean.

Let's look at other examples to get just a hint at how broad this could be.  For example you might raise a PropertyChanged event inside your property Set. That pattern might look a bit like this today

 

   Private m_Name As String

 

   Public Property Name() As String

      Get

         Return m_Name

      End Get

      Set(ByVal value As String)

         If value <> m_Name Then

            m_Name = value

            OnPropertyChanged(Me, New System.ComponentModel.PropertyChangedEventArgs("Name"))

         End If

      End Set

   End Property

 

 

   Protected Sub OnPropertyChanged(ByVal sender As Object, ByVal e As System.ComponentModel.PropertyChangedEventArgs)

      RaiseEvent PropertyChanged(sender, e)

   End Sub

 

 

Wouldn't that be a lot nicer if we could just write that as :


  <RaisesPropertyChanged> _
  Public Property Name() As String


 

Likewise we could start looking at declarative patterns, be it common binding or range validation, etc.  Embrace declarative :)

 


 

30. Allow seeing the types in ambiguous namespaces

In their infinite wisdom, the Windows.Forms team created a System.Window.Forms.ComponentModel namespace.  And because the default imports for a VB Winforms project is System and System.Windows.Forms, you can't use the ComponentModel namespace in either, instead you have to fully qualify it. What a right royal PITE.  You should be able to use the types in there, and only on the types that are ambiguous should this raise an error asking you to qualify the name.

 

.

Filed under: , ,

Comments

# re: VB 10 thoughts (part 8)

Friday, October 12, 2007 8:08 AM by Jim Wooley

To a certain extent, the declaritive validation is already in the works in the Enterprise Library's Validation Application Block. There is a small push for more aspect oriented programming techniques which may take hold in future iterations of the product depending on demand.

# re: VB 10 thoughts (part 8)

Friday, October 12, 2007 8:33 PM by bill

Hi Jim,

AOP wasn't what I had in mind when talking about Declarative codign for VB, at least not in terms of how AOP is done today. Rather than interception or IL injection, I'm talking about compiler generated code, same as we have WithEvents.

Admittedly the boundary between those is blurry, os perhaps a better example would be somethign where you indicate the backing storage, Field versus DependencyProperty, e.g:

<Storage(DependencyProperty)> _

Public Property Name As String

Taking this one step further, you might decide that applies to all properties in your class, so rather than mark each property, you could mark the class:

<Properties: Storage(DependencyProperty)> _

Public Class Customer