Implicitness

Saturday, January 29, 2005

Although porting my Managed Extensions C++ libraries to C++/CLI (the new version as of 2005) isn't strictly necessary due to the /clr:oldsyntax switch, I'll do so happily since the new language is a lot cleaner, more expressive, and supports more features, such as interface mapping, param arrays, a much better array syntax, and above all, a type system overhaul that makes CLR types look natural (handles, tracking references, etc.). C++/CLI is also the simplest .NET language to define a property.

The only gripe I have is about implicit boxing, which should keep me on my toes during the migration:

// old:
__box Int32 * hInt = 0; // null handle 
// new:
Int32 ^ hInt = 0; // implicit boxing 

Implicit boxing isn't really within the spirit of C++. Speaking of implicitness, it's again time to bash VB.NET for all the weird little things that happen in the background, like compiler-defined properties directly under the "My" namespace ("My.Forms" is property, not a class or module), and the partial "MyApplication" class in the a"MyEvents.vb" file (any other parts of said class are nowhere to be found), and worst of all, default instances and the pointless bending of basic language semantics:

Sub Main()
    If Form1 Is Nothing Then
        Application.Run(Form1)
    End If
End Sub

You see, the test evaluates to True even though "Form1" is a property that - normally - lazily creates the default instance, except when used in a test; therefore, the application can be run without an Exception in Application.Run(). The reasoning behind this rule is that it should be possible to test whether or not the default instance is yet created. Now I don't know about you, but if I have some property or method that lazily creates the object it returns, I expect it to behave consistently, regardless of where it is called or why it is evaluated. If I want to find out about the state of the object creation, I expect to do so through another property ("IsForm1Created" or such like).

As I have said in my comments on partial classes, VB.NET is on the way of becoming the ultimate leaky abstraction. Why have all sorts of classes and objects populate the project that I haven't defined, that follow strange rules, and can not even be debugged? When you create a form in the forms designer, there is at least source code, from which you can learn or which you can change if needed.

I like many of the new features in VB.NET, such as generics, custom events, using blocks, unsigned integers, but the wild design fantasies that the VB.NET team suffers from have me reconsidering my relationship with the language.