OK, quick quiz. And, yes, this is a trick question. Without looking at VS, what do you expect the following code to print?

Public Sub Foo()
    Dim s1, s2 As String
    
    s1 = "abc"
    s2.Copy(s1)
    Console.WriteLine(s2)
End Sub

Yes, that’s right, it prints nothing. Wha….? Because String.Copy is a shared function that takes a string and returns a copy of it. It has no effect on the instance that it’s being called on.

Another quick quiz. And, yes, this is also a trick question. Without looking at VS, what do you expect the following code to print?

Public Class Foo
    Public Shared Baz As Integer = 10
End Class
 
Module Test
    Public Function Bar() As Foo
        Console.WriteLine("abc")
        Return New Foo()
    End Function
    
    Sub Main()
        Dim y As Integer
        
        y = Bar().Baz
    End Sub
End Module

Yes, that’s right, it prints nothing. Wha….? Since Baz is a shared member, we do not need to evaluate the qualifying instance expression, so we don’t. So Bar is never called.

In general, it is a bad idea to call shared members off of instance expressions for these two reasons. Shared members cannot affect instances directly, so calling shared methods or changing shared properties/fields off of an instance may give surprising results. And because we do not evaluate expressions that qualify shared members, you won’t get side effects where you might expect it. (This has bitten even a few members of the VB team themselves.)

A legitimate question then is, if it’s a bad idea, why do we allow it in the first place? Unfortunately, the original logic has been lost to history – my grey matter no longer contains the memory of when and why we decided to allow this. One possible reason is that disallowing shared member access off of an instance expression causes problems in a common situation:

Enum Color
    Red
    Blue
    Green
End Enum
 
Class Control
    Public Color As Color = Color.Red
End Control

With just the simple rule that shared members cannot be accessed off of instances, the field declaration in Control would be in error. This is because the Color in Color.Red will bind first to the field Control.Color, which is an instance field. Which means you can’t access shared members off of it, and enum members are shared. C# fixes this problem by introducing a special rule: in a context where the name of a variable is the same as the name of its type, you can access shared instances off of an instance. As it turns out, we had to introduce this rule anyway late in VS 2002 for the following related situation:

Class Control
    Public Color As Color
    
    Public Shared Sub Bar(ByVal SomeControl As Control)
        SomeControl.Color = Color.Red
    End Sub
End Class

In this case, the Color in Color.Red still binds to the instance field, but you run afoul of the rule that says that you can’t access instance members in a shared context.

Whatever the original logic, it’s become clear that this is not a good design and that we made a mistake in allowing it. (Yes, Virginia, we do make occasionally make mistakes around here.) I encourage people to avoid using it whenever possible. Unfortunately, the compiler doesn’t really help you on this today, but it’s something we’re be helping you more with in the future.

I have to agree with this recent article on DevX by Russell Jones.

…those who think Edit and Continue is a good idea and those who don’t. I still haven’t gotten to answering Franz‘s original question, but a recent entry he made does start to address the question.

I totally understand what he’s saying when he talks about the fact that Edit and Continue allows for some very bad programming habits. I spent a few summers teaching teenagers to program, and I got to see first hand some of the ways that bad habits can derail programmers, especially new programmers. From a theoretical standpoint, it is infinitely preferable for programmers to follow the well-worn steps to programming nirvana: understand the problem, design the program structure, implement the program, test the program, fix the bugs, ship the program. In that order.

And yet… The reality is that life is messy and does not always conform to theoretical norms. I am a skilled programmer who works on a major product produced by a large corporation. But even I have lots of times where the code that I write only needs to be “good enough” and not brilliant. I’m not talking about the VB compiler here – obviously, that has to be brilliant – but about all the side projects and throwaway tools and prototypes and test cases that I work on in my day to day life. It doesn’t matter that they’re well designed, only that they work.

And that’s what makes Edit and Continue so wonderful. When I need to bang something out rapidly, I can design the application on the fly. I outline the application, hit F5 and I’m off, writing the code as I go along. If I made a mistake, no problem, I can fix that on the fly without having to restart the entire application. If I’m working on something that really needs to be polished up later, that’s cool – I can do that later. But for now, I’m getting my work done and I’m doing it without all the theoretical design overhead that I really don’t need at that moment. And there are a lot of people in this world who just need to get their work done like this and don’t need to produce well-designed, meticulously thought-out applications. That’s why Edit and Continue is such a big feature for them.

(I’ll also add that I suspect that many, but certainly not all, developers who do not want Edit and Continue haven’t really tried it. Even for people who think fully through their design and eschew debugging on the fly, there is always those times when you hit an exception 10 minutes into running your application and you realize that you just forgot to initialize some stupid variable. If only you could just fix that one damn line and not have to re-run the application again for 10 minutes… If only…)

Anyway, like I said, I’ll freely admit that EnC can enable people to slide by with some pretty bad habits. But if people find it useful, why not do the feature and allow people to decide for themselves whether they’re going to have bad habits? The purpose of a tool is not to make people use it in the “correct” way, the purpose of a tool is to assist people in getting something done. That means that just because someone might misuse a feature does not, in and of itself, mean that you shouldn’t do it. This is really a core philosophy of VB: whatever it takes to give you the shortest path between your idea and a completed application. That’s RAD.

Thanks to Scott and Sean for pointing out that MSDN has published a high-level roadmap for Whidbey and Orcas. I’m planning at some point in the near to talk a little more about some of the details of Whidbey features, especially generics. Not because I have an urge to blab secrets but because I think there’s value in letting people know where things are headed, and even get a chance to get some feedback.