VB 10 thoughts (part 8)
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.
.
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.
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:
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:
Public Class Customer