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…

23 thoughts on “Default Instances

  1. Daniel Moth

    < ![CDATA[No "brickbats" here :-)

    It sounds like contrary to popular demand (as per the ladybug link you referenced) the feature was not removed. So the obvious question is: Are they going to be optional?

    ]]>

    Reply
  2. karl

    < ![CDATA[Paul,

    I’m not familiar with default instances, but the idea is that you can simply use the classname to have an instance created, ala: <CLASSName>.<Property/Function> ? (I want to say similar syntax as accessing shared members, but I realize it’s a totally different thing)

    ]]>

    Reply
  3. Ninputer

    It introduced a little confusion on the concept of class, so there will be somebody doesn’t love it. You can made it optional in the Compiler Options. I don’t mean to turn of My.Forms generating. Just prevent user to access them from the class name. Only open it when upgrades from VB6 programs or when a programmer really knows what it means and want to open it.

    Reply
  4. Merak

    < ![CDATA[As the original poster of the ladybug issue (posted after discussion with a number of people on the VISBAS-L list), I look forward to your 2nd blog on this.

    I’ll leave my comments for those, however I do have a couple of requests:

    Can you please address "Why" it was reintroduced?

    Was it truly a popularly requested feature, or was it just simply easy to implement with the My namespace (ie an intern’s project)?

    Can you also please address how you have learnt from the problems with the VB6 implementation, and how the new version of this feature addresses them?

    (Many of these are discussed in the comments posted to the ladybug site, but mainly boil down to the "accidental" semi-Singleton nature of them..memory of the private vars of previous incarnations, showing a 2nd instance, just to see an already visible one just come to the foreground, etc..behaviour which is sometimes desired, but usually is’nt)

    Thanks]]>

    Reply
  5. Merak

    < ![CDATA[[Daniel Moth]:"...Are they going to be optional?"

    I doubt it will help if they do.

    It would be like saying it’s optional to light a match in a gas filled room…you only have to use the option once to introduce the problem to the project. Afterwards turning the option off will either be impossible, or will produce so many compile-time errors that it would be unfeasible to do so.

    However, if it was introduced with an option, I’d like to see the ability to disable the option completely via enterprise policy/templates (so it can’t be "accidentally" turned on)]]>

    Reply
  6. Len Weaver

    I’m curious… What will happen if one tries to use this feature with a form that lacks a parameterless constructor?

    Reply
  7. Daniel Moth

    < ![CDATA[Merak: You are preaching to the Choir :-)

    In a world where the feature is not removed (which is clearly the case), I can at least ask for the option to disable it in any project my team starts.

    To use your analogy: In a world where everybody strikes a match in gas-filled rooms, I’d like the option not to strike (since I am refused the option to leave the matchbox outside of the building)]]>

    Reply
  8. Andy Maggs

    IMO this feature is only being introduced to enable people to upgrade VB6 apps more easily, and has no other place in .NET. Rather than trying to influence the marketiing folks at MS with arguments about programming purity (a subject for which I imagine they could care less), use C# instead which so far at least has no need for such nonsense.

    Reply
  9. Pingback: notgartner.com: Mitch Denny's Bl

  10. Pingback: Daniel Moth

  11. Scott Swigart

    < ![CDATA[I'm amazed at the amount of complaining about this feature. To me, it's a simple convienence, and you don't have to use it if you don't like it. I also don't see how it's such a step backwards. It's not like "Dim f as new Form1" suddenly stops working...

    ]]>

    Reply
  12. Pingback: Anonymous

  13. Pingback: Anonymous

  14. Tatham Oddie

    < ![CDATA[Uh... I didn't know VB could go any further down hill. I now basically refuse to work on any VB based projects. They go in the same boat as ASP, or VB6 project - in need of a rewrite, development can not continue.

    I always knew that there’d be an ever-increasing number of reasons to support my move to C# almost 3 years ago.]]>

    Reply
  15. pscool

    < ![CDATA[I recently did a research on converting VB6 apps to VB.NET & i realised the various shortcomings VB6 had, default instance being one of them.

    I for one feel one should not use default instances, primarily bcos basics of classes & objects are jeopardised & also any new VB6 projects should be developed keeping Vb.NET in mind.

    At the end of the day it should be easy for maintenance.]]>

    Reply
  16. Pingback: Brad McCabe's WebLog

  17. Dave Markle

    < ![CDATA[This is the worst idea I have heard since implicit typing in FORTRAN.

    It’s not that a talented developer couldn’t ignore this "feature" of the language and write good code in VB.NET. It is possible. It is, rather, that many, many, many BAD developers will [mis]use this feature, and create almost unintelligible guck, leaving us more talented folk to maintain and clean up their messes when they get fired. Oh wait, why am I complaining? I bill by the hour. Never mind! This is an awesome new capability!

    ]]>

    Reply
  18. Pingback: d.code

  19. Pingback: d.code

  20. Pingback: Dennes

  21. Pingback: Anonymous

Leave a Reply