I like semicolons, but underscores like me...
I’m pretty much a C# fan. I admit it, I like semi-colons. Frankly, I think that I’m addicted to them, and I go through withdrawal every time I find myself fumbling through Visual Basic .NET code. I’ll find my fingers sneaking in a friendly ; . Of course, the IDE politely reminds me that I’m an idiot. As soon as possible after my VB.NET experience, I usually scurry back to the comfort of C#.
However, there are a few things that VB.NET just does for you that C #doesn’t. For example, take the following code C# snippet:
using System;
namespace Dennany.Examples.Test
{
class MainClass
{
static void
{
Customer c = new Customer();
c.Name = "Jerry Dennany";
ProcessCustomer.ProcessCustomerName (ref c.Name);
}
}
public class Customer
{
private string _name;
public string Name
{
get
{
return _name;
}
set
{
_name = value;
}
}
}
public class ProcessCustomer
{
static public void ProcessCustomerName(ref string NameProperty)
{
// Do something here
}
}
}
Ahh, I’m ever so fond of closing curly brackets!
However, I’m less fond of the all-too-familiar blue squiggly that you’ll see at this line:
ProcessCustomer.ProcessCustomerName (ref c.Name);
If you compile, you should get the following message:
Error: A property or indexer may not be passed as an out or ref parameter
The reason makes sense. Really, this could only work for the get side of a property or indexer. If the ref parameter was changed during the method’s return, there would be no way for the set operation to take place. That’s why the compiler doesn’t allow this operation.
However, let’s take a look at the same code, only converted to VB.NET. (And please, let’s not be pedantic about the translation…)
Module MainModule
Sub
Dim c As New Customer()
c.Name = "Jerry Dennany"
ProcessCustomer.ProcessCustomerName(c.Name)
End Sub
End Module
Class Customer
Private _name As String
Public Property Name() As String
Get
Return _name
End Get
Set(ByVal value As String)
_name = value
End Set
End Property
End Class
Class ProcessCustomer
Public Shared Sub ProcessCustomerName(ByRef CustomerName As String)
' Do something here
End Sub
End Class
This time, we get no blue squiggly! Now, there’s a .NET CLR constraint against a set taking place, so what’s going on here?
Well, if we look behind the scenes, here’s how the VB.NET compiler actually codes this:
Public Shared Sub
Dim c As Customer = New Customer
c.Name = "Jerry Dennany"
Dim c2 As Customer = c
Dim tempText As String = c2.Name
ProcessCustomer. ProcessCustomerName(tempText)
c2.Name = tempText
End Sub
It makes sense, now that we look at the code generation done behind the scenes by the VB.NET compiler. By setting a temporary variable, and then resetting the original property, VB.NET solves this issue. Now, many C# people may be looking at this and wondering why this is a big deal. It’s not, really, but it’s an example of how the VB.NET compiler goes that extra mile.
I ran into this recently when I was converting a very large VB.NET project to C#. There were several hundred places in the code where this occurred, and this issue, along with many others, rendered the conversion very difficult to perform. So, the next time someone tries to tell you that VB.NET and C# are the same thing, you might want to politely remind them that enough small differences make switching languages non-trivial on a large project.