What is the reason for not instantiating an object at the time of declaration?

Question

I had to delve into some VB6 code recently and I saw this pattern all over the place:

dim o as obj
set o = new obj

Why not this?

Answer 1

Here's another caveat:

For x = 1 to 100
   dim obj as new MyObject

   'Do something with obj
Next

You might expect that a new object is instantiated 100 times, but you'll find that it only gets instantiated the very first time. This one caught me off guard long ago.

I still use this notation all the time though. Just make sure you know the behavior.

Answer 2

I wanted to add to Brandon Moore's answer...

So continuing from the loop...

For x = 1 to 100
  Dim obj as New Collection
  obj.Add "New String Number " & x
Next x

Even though you've added say 20 items to obj when x = 1, when x = 2 all those 20 items will still be there! whereas, if you did set obj= new myObject then it would not! This is the most significant reason, as i once got caught out in this in a big looping area in my code, stuff was being added throughout the program and I had no idea why, nothing was being deleted or reset.

So, If instead of:

  Dim obj as New Collection

You wrote the foilowing:

  Dim obj as Collection
  Set obj = New Collection

Then you would have the obj Collection being reset every single time, which is probably what you want, but if you only want it to set Once, then use the As New Collection method. But, if you jsut wanted to set it once, you'd probably put it outside the loop.

Also, if you are not running in a loop, but the variable (Collection) is defined in a static function, or is defined with the static keyword, the exact same thing applies, not running the Set obj = New Collection will ensure you have stale data from your last use of the obj/Collection, which can be very bad.

So, in conclusion, the two methods are actually very different (and can have different behaviour)!

Answer 3

This question touches on one of the many reasons that experienced programmers really dislike VB6. The New keyword changes the way the declared variable works. For instance:

Dim MyObject As MyClass
Set MyObject = New MyClass
Set MyObject = Nothing
Call MyObject.MyMethod()

... throws a runtime exception, while this:

Dim MyObject As New MyClass
Set MyObject = Nothing
Call MyObject.MyMethod()

... does not. Personally, if I go to the effort of setting a variable to Nothing, then referencing it again is almost certainly an error and I'd really like the program to crash, thank you very much. It's particularly important in the case where the class allocates resources in the initializer (constructor) and needs to get rid of those in the destructor. It's reasonably easy to write code that incorrectly references variable set to Nothing, perhaps when you want to check a result value or something. Doing this could cause the class to be instantiated again, grabbing all the unnecessary resources.

The reason for this weird behavior is so that VB6's forms (which are classes) work the way a novice would expect them to work. There's an implicitly declared global variable with the same name and type as each defined form, so:

Call frmMain.Show

... doesn't crash. This is the same behavior. It's really doing:

If frmMain Is Nothing Then
    Set frmMain = New frmMain
End If
Call frmMain.Show

This very much goes against what we're used to in other object oriented languages, so, in my opinion it's a bad idea. It's trying to hide the fact that MyObject is a reference type, and yet, when you write something like this (without using Set):

MyObject = New MyClass

... then you get a runtime exception instead of a compiler error because you didn't use the Set command. The compiler knows it's a reference type... why do I have to use Set, and even if I do, why not tell me about it sooner?

At any rate, to answer your question, you rarely want the behavior implied by using the Dim ... New syntax because you want to control the construction and destruction of objects. In fact, the only time it would ever make sense is in the construction of global singleton objects (such as frmMain above) where you just want the syntactic sugar. I would argue that global singletons are a bad idea anyway, so if I could turn off the ability to use the Dim ... New syntax, I would.

Answer 4

There may be other reasons but in VB6 using the New keyword when you Dim an object can cause unexpected results because VB will instantiate the object whenever it is referenced.

Dim objMyObject as New SomeObject

Set objMyObject = Nothing   ' the object is nothing

If objMyObject Is Nothing Then  ' referencing the object instantiates again
   MsgBox "My object is destroyed"  ' what you would probably expect
Else
   MsgBox "My object still exists"
End If