Ted Neward has an interesting take on the VB mentality and it’s meaning in an entry entitled “The problem of “Do It Yourself” and Java”. A small quote:

[…] The VB community has long been a community that focuses on “getting the job done”, no matter what it takes, which of course to the ears of a C++ guy has that evil and despised overtone of “HACK” written all over it. The C++ guy would MUCH rather find the elegant solution, rather than live with code that smells. Unfortunately, this sort of thinking tends to lead towards solutions that are single-shot and specific to the project (if not the company) that creates it. […] It’s a problem I’d never seen before until I started spending more time in the company of those who actually come from that community. […] Don’t believe me? Take some time to hang out with the local VB crowd for a while, and just see how different their approach, styles, and thought patterns are. And don’t, for God’s sake, look down on their way of doing things, or you’ll be missing the point entirely.

The entry is definitely worth checking out!

I can’t believe I’m the first person to blog about this (maybe my aggregator’s stuck?), but the new Visual Basic Power Pack has been released on GDN. Here’s a description:

The Visual Basic Power Pack consists of seven custom controls written in Visual Basic .NET 2003. The controls provide enhanced user interface elements and enable you to create more interesting and more colorful client based applications.

The Power Pack controls consist of:

·         BlendPanel. This provides a background for a form where the color fades from one shade to another.

·         UtilityToolbar. This is a toolbar whose look and feel is similar to the Internet Explorer toolbar.

·         ImageButton. This is a button that displays a graphic over a transparent background.

·         NotificationWindow. This displays text and graphics in a pop-up window (commonly known as “toast”).

·         TaskPane. This is a container that provides collapsible frames for displaying additional information on a form.

·         FolderViewer. This displays directories in a hierarchical format.

·         FileViewer. This displays a list of the files in a specified directory.

They’re being released as a sample, so full source code (in VB, of course!) is available. Have fun!

Duncan pointed me to a thread on GotDotNet that asked a frequently asked question: why doesn’t For Each require a cast when Option Strict is on? For example, the following code is entirely legal:

Option Strict On
...
Sub Foo(ByVal array() As Long)
    For Each i As Integer In array
        ...
    Next i
End Sub

As For Each iterates through the array, each element of the array is automatically cast from Long down to Integer without comment, even though Option Strict usually requires an explicit cast. Why is that? Mostly for developer convenience with dealing with collections such as Collection or Arraylist. In those cases, the element type of the collection is always Object. If we required a cast to iterate through a collection of Object values, where would you put the cast? There’s no place to actually do the cast in the For Each statement, so you’d be stuck having to have your iterator variable be typed as Object and then doing the cast yourself into anoher variable:

Option Strict On
...
Sub Foo(ByVal array As ArrayList)
    For Each o As Object In array
        Dim i As Integer = CInt(o)
        ...
    Next i
End Sub

Since ArrayList/Collection object tend to have the same type in them and people iterate through them a lot, we decided that it made more sense to bend the rules in this case and do the cast automatically for you. (You can thank us later.) As an interesting side-note, C# does exactly the same thing in their foreach statement.

In my entry on “native” languages on the CLR, I made a blanket statement that the intrinsic VB conversion operators would be faster than the conversion functions in the Convert class because they compile down to IL rather than function calls. In my quest to emphasize my point, however, I made a serious misstatement which was not intentional but should be corrected. Not all intrisic operators compile down to simple IL instructions, although most do so. And the ones that don’t are worth discussing. So let me spend a moment talking about conversions.

The intrinsic conversion operators (CObj, CByte, CShort, CInt, CLng, CDec, CSng, CDbl, CDate, CStr, CChar, CType, DirectCast) generally fall into several broad categories of implementation:

1. Conversions that are pure IL statements. The best example here is the conversion from Integer to Long or Long to Integer. This compiles directly down to a conv.i8 or conv.i4.ovf instruction, respectively. You really, really, really don’t want to be calling functions to do this kind of conversion unless you’ve got a lot of faith in inliners, which I generally don’t.
2. Conversions that are mostly pure IL statements. The best example here is the conversion from Double to Integer. This compiles down to a call to Math.Round and then a conv.i4.ovf instruction. The purpose of the extra call is to implement banker’s rounding, which the CLR doesn’t natively support. (In banker’s rounding, a decimal number equidistant between two whole numbers is rounded to the nearest even number. So 3.5 rounds to 4, but 2.5 rounds to 2.) In this case, calling Convert.ToInt32(Double) is not the same as CInt(Double), and you have to choose which semantic you desire.
3. Conversions that are calls to the Convert class. The Decimal type is not natively supported by the CLR. As such, conversions to and from Decimal (with the exceptions listed below) turn into calls to Convert.ToDecimal() or the appropriate helper. There’s no point in us reimplementing the conversion since it’s the same for both the CLR and VB. In this case, calling Convert.ToDecimal(Integer) is exactly the same as CDec(Integer).
4. Conversions that call VB specific helpers. There are only two cases that fall into this category: conversions to and from String, and conversions from Object.
• Conversions to and from String call VB specific helpers because VB does a variety of extra things for you. For example, when converting String to Integer, we’ll parse decimal numbers and do the appropriate rounding. So while Convert.ToInt32(“10.5“) will barf with an exception, CInt(“10.5“) will work just fine. And this is just one example of the nice stuff that we’ll do for you. As always, though, extra functionality can equal extra cost. So if you just want the very basic functionality that Convert.ToInt32() calls (or you prefer calling two functions), you might get slightly better performance by calling it instead of using CInt on a String.
• Conversions from Object call VB specific helpers because VB needs to be able to implement VB specific semantics (such as the String conversions and banker’s rounding) when converting values from one type to another. For example, Convert.ToInt32(CObj(“10.5“)) still throws an exception, while CInt(CObj(“10.5“)) won’t.

One interesting thing to note is that if you really want only the CLR conversions and nothing else, the DirectCast operator will turn off most of the VB-specific conversion features (I believe we still do banker’s rounding, though). Then you can call the Convert class methods when you run into conversions that DirectCast doesn’t support. I still think that this is an extreme way to go about things, but I know some people are just that way. Me, I use the regular VB operators and then look out for performance sensitive areas where I might need something different.

…can be found here. Good to see more from Cameron!