Archives

Archives / 2004 / October
  • 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 Main(string[] args)

            {

                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 Main()

            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 Main()

        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.

    Read more...