The VB team blog has listed the upcoming team chats, but I thought I’d also put in a word for one I’m going to be participating in. Also, if there are any topics that you’d like to see, just leave a comment and I’ll pass it along!

Visual Basic 2005 Language Enhancements
Visual Basic 2005 has many new and improved language features, including generic types, operator overloading, compiler warnings, partial classes, mixed access properties, unsigned data types, and more. Join members of the Visual Basic team to discuss these features. Provide the team with your feedback about the Beta version and get answers to your questions.

August 12, 2004
1:00 – 2:00 P.M. Pacific time
4:00 – 5:00 P.M. Eastern time
20:00 – 21:00 GMT
Add to Outlook Calendar
Tell a Friend

In the comments to my previous entry on partial types, mustTryHarder comments:

If C# always uses the partial keyword (and presumably went through the same level of debate) then why did the VB team approach it differently? I assume you guys talk to each other. I can’t see how Microsoft can justify a difference. While virtually everyone agrees that separation of designer code is desirable, it would appear that only the VB team feel the Partial keyword is optional. IMHO the VB team would do well to listen to feedback on syntax in order to avoid the same back-tracking in future that happened with areas such as properties which are now once again able to specify different accessibility levels for Get/Set. So far your private debates have got it wrong!

mustTryHarder’s comments are contradictory, although there was no way for him to know that ahead of time. You see, the reason why VB didn’t support properties with different levels of accessibility in VB 2002 and VB 2003 is because the C# team didn’t want to support them. Our original plan was to include them just the way they were in VB6 but the C# design team was very definite that they thought they were a bad idea and that they weren’t going to include them in their language. As a result, when the C# compiler came across a property with different levels of accessibility, they would consider the property’s accessibility to be the more restrictive of the two. So if we’d gone ahead and implemented the feature anyway, a property with a Public Get and a Private Set would have been considered Private by C#, which would have looked a lot like a bug to most people. So we made the decision to not implement the feature in the interest of playing well on the .NET platform. Fortunately, everyone’s come around in VS 2005, so the feature is going to appear in both languages and there aren’t going to be any difficulties.

So, ironically, in this case we’re getting simulateously criticized for not doing the same thing as C# is doing and for doing the same thing as C# did. Welcome to the world of multi-language programming on the .NET platform, folks. We’re not in Kansas anymore.

The truth is, we have a lot of regular contact with the C# team about design decisions and feature choices and, where it makes sense, we try and be harmonious. However, each language’s design team has distinct visions for their language and that is inevitably going to cause divergence. For example, I know that more than a few people on the C# team (and more than a few C# users) think that our generics syntax is stupid. I can see where they might be coming from in having that opinion, but I disagree with it… and that’s the way it goes. Should VB users not get Edit and Continue because the C# team doesn’t think that it’s important enough to ship in VS 2005? Should C# users not get iterators because VB doesn’t think that it’s important enough to ship in VS 2005? Who gets to decide which vision is the “right“ one? Who’s even to say that there is a single “right“ vision for the millions and millions of developers out there in the world?

I should be clear that what I’m not saying is that people shouldn’t feel free to complain loudly about things that they don’t like about VB. That feedback is invaluable and helps guide the future direction of the language. What I am saying, though, is that one argument that is never going to work with us is “But C# does it differently and you both should do everything the same way!” If there are concrete reasons why you think the C# design is better, then let’s hear them and we can have a good discussion about the merits and demerits of the VB approach. Otherwise…

Andy Maggs asks:

Who thought it was cool to be able to create partial classes without indicating on the ‘primary’ class that it has other parts somewhere else. In C# you must use the partial keyword on all parts, so why not VB?

Since partial type cannot span projects (i.e. a type must be fully described inside of a project), we felt it was sufficient to only have to have at least one of the declarations “opt in” to partialness. Requiring every partial declaration to have to specify that it was partial seemed to be unnecessarily strict. For example, in the designer case such as a WinForm, it is really necessary to put “Partial” on the class declaration when the partial type that the designer spits isn’t even shown by default?

And, of course, there’s no reason that a developer can’t specify “Partial“ on all partial declarations if they so choose. You can even modify, say, the WinForms template to add it if you want.

In the end, this is one of those things I was talking about just last week, a real judgement call. There are more than a few people who have taken issue with this particular decision, feeling that the more explicit the better. (There have been even suggestions made to us that partial types should have to explicitly state which source file the other partial types reside.) I can see their point and don’t think their arguments are bad, we just don’t happen to agree on this…

OK, I’ll admit it – there are actually times when I think features that we’re introducing are stupid. (Of course, they’re always someone else’s features, never my own…) One such example was the reappearance of something we call “zero-impact projects.” A zero-impact project is a project that is created on-the-fly in a temporary directory rather than being saved somewhere permanent like your Projects directory. You don’t have to create something permanent until you do something like shut down the IDE or close the project. VB6 did this, but VB7 didn’t, and I personally never thought much about it. When I found out we were doing the work to restore it, I though, “Ah, that’s dumb. Who really cares about this? All it does is save you having to pick a place for your project… Grumble, grumble.”

Well, let me publicly eat my words: munch, munch, munch. I’ve switched to VB 2005 Beta 1 full time for the stuff that I’m working on and zero-impact projects absolutely rock! One of the things I’m doing right now is updating the language specification for VB 2005 and it’s just great to be able to bring up VS, create a VB project, play around for a little while and then close down VS without having anything left behind on my computer. No more “ConsoleApplication491349” projects! I mean, I was right in one way – it’s a little thing, but, boy, it does make a difference. (The faster startup time of the IDE also helps immensely.)

If you aren’t using the VB profile, you can enable zero-impact install by clicking on the “Projects and Solutions” entry in the Tools | Options dialog and unchecking “Save new projects when created.” It’ll even work for C# projects! (Although this feature might be a little too “edit and continue”y for those C# folks… <g>)

We now also have a generics whitepaper on MSDN, written by the developer who’s been implementing a lot of the generics support in VB! I know a lot of people still think that VB 2005 isn’t going to support generics, but here’s the real deal…

Just an FYI to everyone, the following chat is coming up on July 13, 1:00 – 2:00 P.M. Pacific time:

Visual Basic 2005 Language Enhancements
Visual Basic 2005 has many new and improved language features, including generic types, operator overloading, compiler warnings, partial classes, mixed access properties, unsigned data types, and more. Join members of the Visual Basic team to discuss these features. Provide the team with your feedback about the Beta version and get answers to your questions.

I’ll be there, I hope you will be too!

Add to Outlook Calendar

One of the nice things about reaching beta is that we’re now starting to get more whitepapers out there on new features, which reduces the number of things that I feel guilty about having not blogged about yet. The latest example of this is a whitepaper on Operator Overloading in Visual Basic 2005 written by Matt Gertz, the development lead for the VB compiler (my old job, for those of you keeping score). It’s a great overview of what we’re doing with overloaded operators, so check it out!

Now we just need a whitepaper on generics…

VB 2005 Beta 1 (as well as the beta of those “other” languages) is now available. Not only that, but VB Express, a lightweight version of the product is also available (and there’s an Express weblog). The cool, new MSDN Product Feedback Center is on-line now, ready to take your suggestions and bugs. And, finally Channel 9 is running a contest for applications written in VB express. Check it all out!

Via Duncan, Ken Getz has written an article on the new features coming in VB 2005 (Whidbey). Check it out!

Erik Porter talks briefly about two VB 2005 features that haven’t been talked about as much: properties with different levels of accessibility and multiple attributes. Check them out!