What happened to my () at the end of my initialization?


In VB.NET 2003, when you create an instance of a class and there are no parameters to pass to the constructor, the parentheses will not show.  You can type them, but the editor will remove them.  They didn’t disappear in VB.NET 2002.

    myNewObject = New Foo()
will turn into
    myNewObject = New Foo

No matter what you do, those parentheses will not remain.  Why?  I asked one of the program managers on the VB.NET team.  He said that having empty parentheses was too confusing for people.  In VB you can use empty parentheses for declaring arrays.  People would end up accidentally declaring an array of something rather than creating an instance of something.

I don’t buy it.  I think they should have left the parentheses on there.

Comments (5)

  1. Rory says:

    I totally agree with you. I’m not much of a VB person, but I’ve been having to do a bit this week, and have been reminded through a series of harsh lessons that one of VB’s greatest weaknesses is the occasional lack of *consistency*.

    For example, the "Set" keyword (talking about pre .NET days here) is one that just drives me nuts. Why I should have to pump an extra keyword into a line in order instantiate a class is beyond me. I was going to write a clever little code generation tool today (long story) that was going to consume some VB6 COM+ stuff and convert it to loosely-typed ASP stuff (another long story). The generated code was going to act as a wrapper around calls back to the middle tier (yet another long story). I stopped short of finishing when it dawned on me that I was going to have to do some extra footwork to determine if the function return type was going to require "Set" or not (not quite as trivial as it sounds). I still haven’t decided if I’d rather just create the wrappers by hand, or if I ought to pick up where I left off.

    Not entirely related to the post, but an example of why consistency is important, and how VB has thrown a wrench into my little plans by doing things in weird ways.

    So, yeah – The parens really should be there.

    MS has had a chance to start over with VB.NET – Now’s the time to not make any big mistakes.

  2. Phil Scott says:

    I also agree with you…to a point. I teach a lot of "intro to vb.net" classes, and I can say that when we are doing labs at least once every ten minutes someone accidentally creates an array of items after they remove the new keyword from their code.

    Drives them crazy. The first time I saw it kinda threw me off in class too. I’ve never really had the problem of switching back and forth between using new on dim statements. So I really never noticed it in class. So of course the first thing you don’t notice in 2003 is the thing students notice right away 🙂

  3. jim blizzard says:

    I’m for consistency. At the very least they could have created a setting in Tools | Options that allows a developer to decide. Heh. Then everyone would be confused even more. "Why are there parens in this program? Why aren’t there parens in that program? They’re both VB, damn it!" 😉

  4. It sure doesn’t improve code readability, because an important fact is hidden, that fact of calling the constructor with _no_ arguments. What happens if there are objects that do have an other set of constructors?

    I’m not convinced it’s a good idea to change a languages syntax each year just a little bit, this will make code maintanance in the long run (10 years, or more) a ride through hell it self.

  5. Jon Kale says:

    This would seem like an apposite time to reference http://www.ddj.com/documents/s=1503/ddj0001vs/jan00.htm and to tell you all to quit yer whinging – where’d VB (any flavour) be without wierd-ass and needlessly obscure behaviour, eh? After all, if it was easy, all us old C hacks’d be writing it 🙂