Category Archives: Visual Basic 2005

Oh, and, yeah, we launched, too…

In case anyone missed it, we launched Visual Basic 2005 this Monday (along with a couple of other small products like SQL Server and the rest of Visual Studio)! This means everyone can now get their mitts on VB 2005 — you can also get trial downloads and the free-as-in-beer-for-a-year Express version.

 

We’ve also updated the VB Dev Center, so check it out! Now the fun can begin…

Oh, and, yeah, we shipped…!

Since it’s been a long while since I’ve been really closely involved with VB2005, this seems like a strangely anti-climatic announcement, but: we’ve shipped!

Visual Studio 2005 (Standard, Pro, and Express versions) and SQL Server 20005 are now available for download on MSDN if you’re a subscriber, otherwise you’ll have to wait until after the November 7th launch event.

For a good overview of the new features in Visual Basic 2005 check out Ken Getz’s article.  You can also find a collection of VB 2005 articles at our developer center.

Updated 10/27/05: Corrected MSDN link. Thanks Serge!

Language Specification 8.0 (Beta2) now available…

It’s a little later than planned, but we’ve now got the 8.0 VB language specification posted up for downloading. It covers all the new language features in VB 2005 and should be completely current with Beta2. Please let me know of any errors or corrections – it is a beta document, so it’s not going to be perfect.

In case anyone is wondering about 8.0 vs. 2005, the language itself is referred to by a version number, but the product has a year. So:

  • VB 2002 product contains Visual Basic 7.0 language
  • VB 2003 product contains Visual Basic 7.1 language
  • VB 2005 product contains Visual Basic 8.0 language

 

Imperfect Feedback Loops

In one of the comments on my Community Can Be Cruel entry, Karl said:

One of the problems with custom engagement in the forms of these blogs is that it makes the customer believe he or she might be able provide input which will ultimately have an effect on decisions taken. While this may be true in some cases, it certainly isn’t in others. This isn’t anything wrong on your part, and I certainly don’t want you to stop, it’s just hard sometimes for the community to accept that decisions have been made and that our arguments via feedback are, at best, good theoretical debates.

I think Karl’s right that people end up feeling this way, and it’s something that is partially unavoidable and partially due to the way this product cycle has run. On the unavoidable side of things, there’s no getting around the reality that when a complete consensus cannot be reached someone ultimately has to make the decision. To take the example of the default instances debate, we really did listen to all the comments that people made concerning the feature and discussed them seriously. And, belying our Borg reputation, there was a lively debate internally about the feature, with people on all sides of the issue. This included people who, I should say, voiced many of the same concerns and objections that community members did. In the end, though, a decision had to be made and one choice among the many chosen. I know that when a choice is made that doesn’t agree with your opinions, and especially when those opinions are shared among others in your particular network, it can seem very much like your opinion wasn’t listened to or valued even if was taken into full consideration. We do our best to try and let people know that we listened and be up front about our reasons for taking a different course, but some difficult feelings are probably inevitable.

That aside, though, I think that there has been an extra level of angst about feedback this time around due to factors that aren’t inherent in the development process. The nature of things is that many product design decisions are made well before a beta ever ships. While we always can and do make changes based on beta feedback, the truth is that some decisions are hard to change unless they are caught very early because of the size or the risk the change would entail. Similarly, by the time that a beta is out most of the new feature development time has been used up, so feedback on priorities (i.e. “I want feature x more than I want feature y.”) can be difficult to react to, especially if the features requiring significant development investment.

The problem with the Whidbey cycle is that many of the community engagements that we’re now using to gather feedback (forums, blogs, MSDN Product Feedback Center) didn’t come online until later in the product cycle. I believe the product feedback center came online during Beta1. The forums are coming online in Beta2. Even this blog didn’t really get going until the winter of 2003/spring of 2004. What this means is that a lot of the feedback mechanisms that many of you are participating in now didn’t exist early on in the product cycle when many of the critical decisions were being made. This isn’t to say that there was no feedback – we have lots of traditional feedback channels that were being consulted throughout the cycle – just that many of the communities that are now plugged directly into the feedback loop weren’t there. That’s the bad news. The good news, of course, is that as we approach the dénouement of this release and start gearing up to look beyond, you’re all going to be right there from the beginning.

And, finally, there have been some interesting rumblings from my management chain about moving towards an even more transparent development process in the future. How this will play out is unclear to me, but I think there may be some interesting experiments in community engagement coming…

Refactoring: For VB 2005!

As someone very wise once said, the problem with making confident predictions about the future is that time has a way of making a liar out of you despite your best intentions. The good news in this case, in case you haven’t heard it elsewhere, is that VB 2005 will have refactoring features! Both Brad and Cory have some good discussion on this and you can check out the official announcement on MSDN. Personally, I think this is just great and kudos to the VB folks and the Developer Express folks who made this happen.

I will also observe that the old debate appears to be settled for the moment, at least…

Default Instance Considered Harmful…?

Way back in the mists of time (better known as January), I wrote two entries on the default instance feature we’re reintroducing in 2005. The first talked about what default instances are and the second talked about why we thought they were a good idea. I promised at the time to talk about the criticisms that have been leveled against the feature “soon,” but that “soon” has turned into “two and a half months or so.” This is partially because my work load suddenly ramped up, but it’s more because my blog entries and the accompanying comments prompted another round of internal discussion over the feature. That, unfortunately, took much longer than I wanted it to, which further delayed this (since I didn’t want to say one thing only to have to take it back later). So I apologize for the delay in getting back to this.

Anyway, now that we’re past that, the objections to default instances seem to tend to boil down to two major issues:

First, although default instances exhibit most of the attributes of singleton objects, they are really only “semi-singletons” because they can still be instantiated. In other words, in addition to saying Form1.Show(), you can also say “x = New Form1()” and then “x.Show()”. When you use New, you’re creating a second (or third or fourth…) instance of Form1 that is totally separate from the default instance. The relationship between the singleton form and the instantiated form can be obscure at best, causing confusion between the singleton nature of the default instance and the multi-instance behavior of the normal type.

Second, a default instance that can be accessed through the type name (at present, only form default instances do this) erases the distinction between instance and shared members. When I say “Form1.x,” I have no way of knowing, without looking at the object browser or MSDN help, whether “x” is a shared member or an instance member.

(There is a third objection that because non-dialog Windows Forms lose state when they close, default instances are not as useful as they were in VB6. This is a limitation of the Windows Forms design, not VB – when a form closes, everything on the form is disposed, including the controls. Bill proposed a workaround that, I’ll confess, I don’t entirely understand, but it’s something we’re talking to the Windows Forms teams about, although I wouldn’t expect anything for VB 2005.)

The bottom line is that both of the major criticisms of default instances are valid. Despite their usefulness, they do create some semantic confusion that did not exist in the language prior to their re-introduction. Why, then, did we do it? In the end, we felt that, on the balance, the semantic confusion created by the feature was greatly outweighed by its usefulness. Working with forms (and, in VB 2005, web services) as default instances is a very natural and understandable way of doing things, regardless of experience level or knowledge of the language. In our continuing quest to make Visual Basic the most approachable and easy to work with language, this seemed like a very natural feature, not just because it happens to be compatible with VB6.

The standard rejoinder to this line of argument is, “well, fine, re-introduce the feature if you must, but why must you make me have to deal with it?” In other words, “why aren’t default instances optional?” This has been the subject of many long-running discussions internally and we’re open to the idea, but found no good way to do so in this release. We considered introducing a single instance/multi-instance mode switch into Windows Forms, but that would mean that changing the instancing mode of a form would cause drastic changes in the way the form was used in code. Thus, it would be vital to choose up-front whether a form was going to be single instance or multi-instance, and woe be unto the developer who chose incorrectly. We just didn’t feel that was a good user model for the feature.

The other major idea we considered was introducing some kind of configurable warning into the product that would allow people to turn the use of a default instance into a warning or error. This seemed much more palatable, but ultimately died because of what it would imply: warnings and errors indicate code that is probably or definitely wrong. They’re intended to ferret out errors, so adding a “warn on use of default instance” warning would imply, well, that using a default instance is an error, which is something that we don’t believe.

So, where does that leave us? One idea that we’ve started to kick around is the idea of integrating the concept of a “programming style” into the product. In other words, if your programming style is to not use default instances, great – you set that style parameter and then the compiler will warn you when you violate that style. Once you start down this path, you can imagine a great number of possible style settings that the compiler could flag – things that are entirely legal and valid, but which someone somewhere might not like. Unfortunately, this kind of feature is well beyond our VB 2005 schedule. However, as we start to think beyond our existing release, we’d love to hear what you think about the idea!

(For the less-aged among my readers, the title of this piece refers in an ironic way to the seminal paper Go To Statement Considered Harmful by Edsger W. Dijkstra, one of the founding luminaries of the computer science field. I would also note in passing that Visual Basic still has a GoTo statement…)

Singletons and Default Instances

In my previous entry, I described what default instances are but left open the question of why we’re re-introducing them into the language. So let me spend a moment discussing that.

A default instance is, more or less, an instance of the design pattern called a singleton. A singleton is a type that only ever has one instance (hence the “single” part of “singleton”). Forms are often an excellent example of singletons because there is usually only ever going to be one instance of the form (with the exception of less common situations like MDI windows). For example, you only need one instance of the File Open dialog because there will only ever be one File Open dialog on the screen at a time. Rather than having to allocate an instance of the dialog every time you need one, or holding on to the same instance in some random place in your application, a singleton has a central location where the single instance is stored.

In most languages, you have to manage singleton objects yourself. This is usually accomplished by sealing the type (i.e. making it NotInheritable), making it uninstantiable (i.e. making its constructor Private) and exposing a shared property called something like DefaultInstance that returns, well, the default instance. If only the language would do that management for you automatically, how nice would that be? If only…

So now we arrive at the rationale for default instances, aka singletons: we think it’s a more natural way of working with objects that always or almost always have a single instance.

I’ve been using forms as an example up until this point, but let me expand the scope a little bit to illustrate my point. Web services are another example of a natural singleton object. When an application interfaces with a remote web service, there is typically only ever going to be one web service proxy instantiated. In VB 2002 and 2003, it is necessary to create a new instance of a web service proxy and then hold on to that instance for as long as you wish to use the service. If you wanted to share the service across multiple objects, you had to make sure to store the instance somewhere where everyone who needed it could get at it. And, truth be told, all of this management code had nothing to do with your program logic. It was just boilerplate that everyone has to write again and again and again.

In constrast, VB 2005 adds a default instance to web services. When you add a reference to a web service Bob, you automatically get a default instance at My.WebServices.Bob. No need to remember to create an instance of the proxy. No need to sock that proxy away somewhere so that everyone can get at it. It’s just… there. Without you having to do anything to make it so.

This seems like a good thing, but don’t just take my word for it. After all, you can go read about how to implement the singleton pattern in C# and how to implement singleton forms in C#. And then you can come back to VB and find that we already did it for you… (I should add that Justin’s singleton form entry touches on a specific problem having to do with the design of WinForms that I’ll address in the next entry.)

Well, that’s about it for the moment but we’re not done yet… I still need to cover the problems and issues that have been raised around default instances, which I will cover next. That entry, tentatively titled “Default Instances Considered Harmful” is coming soon.

]]>

Default Instances

Fresh off of writer’s block, I thought I’d dive straight back into the sea of controversy and talk about a feature called “default instances.” Default instances are a “new” feature in VB 2005 that is really the return of a very old feature, one that’s been around for a long time. Now, the return of default instances has stirred some very passionate debate, but what I’m going to do is address this question in three separate entries. In this entry, I’m going to describe what default instances are at a technical level. In my next entry, I’m going to talk about what I see as the positive case for default instances. Then, in the final entry, I will talk about some limitations of default instances and address the controversy about their reintroduction more directly. You can choose whether or not you want to wait for the last entry before you start throwing brickbats…

So, what are default instances? Well, they’re exactly what their name suggests: a way to provide a default instance of a class that you can use without having to New the class. If you’ve used versions of VB prior to VB 2002 (i.e. pre-.NET), you’ll probably have come across the most common default instance, the form default instance. For example, in VB 6.0, if you created a form named Test, you could say in code:

Test.Show()

And voila! an instance of the form would just magically appear. What was going on behind the scenes was a bit of magic. When you referred to “Test,” the VB runtime would go check and see if it already had a default instance of Test lying around. If it did, then it would hand back that default instance when you called Show(). If there wasn’t a default instance lying around, the runtime would create a new instance of Test and use that as the default instance going forward.

Default instances disappeared in VB 2002 and VB 2003, but are making a comeback in VB 2005. The high-level “why,” I’ll leave to my second entry, so let’s talk about the “how” for the moment. Hopefully, all of you are familiar with the introduction of the My namespace in VB 2005. (If not, go read this MSDN article and then come back.) One part of the My namespace is the Forms object. If you bring up a VB 2005 project with a Form named Test in it, you’ll notice that the My.Forms object has a property called Test. This property returns a default instance of Test. So you can say, sort of like you did in VB 6.0, “My.Forms.Test.Show()” and voila! up pops a new instance of Test. What happens behind the scenes is that the Test property of My.Forms checks to see if it’s already returned an instance of Test and, if it has, it just returns that instance. If it hasn’t returned an instance yet, it just creates a new instance. Pretty simple.

We also extended default instances to work in exactly the same way that VB 6.0 default instances did. Besides saying My.Forms.Test.Show(), you can also just say Test.Show() and it will also access the default instance. Essentially, Test.Show() is a shortcut to saying My.Forms.Test.Show().

There are, however, a couple of differences between the way default instances are implemented in VB6 and the way they are implemented in VB 2005:

  • In VB6, if you tried to use the Is operator to test the default instance to see if it was Nothing, the expression would always evaluate to False. This is because referring to the default instance caused it to be created if it didn’t exist! In VB 2005, we recognize when you are testing the default instance using the Is (or IsNot) operator and won’t auto-create the instance in that case. So you can see if the default instance exists or not.
  • A common source of default instance errors was using the default instance instead of Me within the default instance’s type. For example, if Form1’s load method has the statement “Form1.BackColor = Color.Red”, this will only change the background color of the deafult instance’s form. If you create a new instance of Form1 that is not the default instance, it’s background color will not be red! To assist users in this case, we give an error when you refer to the default instance inside of the type, telling you to use Me instead.

Well, that’s about it for the technical side of things. Now onto the good, the bad and the ugly…