Things We Hate About Visual Basic Dot Net

Things we hate about VisualBasicDotNet:

(...a good healthy rant inspired by ThingsWeHateAboutVbClassic. New! Improved! And updated for VisualBasicDotNet. ;-)

Not to be confused with ThingsWeLoveAboutVisualBasicDotNet.

(Scope question: I assume this is about MS's new BASIC language dialect and not the "dot net" framework and excludes C-sharp?)

---

List:

• Overrides, Overloads and Shadows confusion.
• Lack of C#(CsharpLanguage)-style auto-properties.
• CodeSnippetsEncourageDuplicatedCode!
• "ByVal" should be the default so that we don't have to clutter code with it since it's roughly the 90% case.
  • [It is the default. You may be thinking of VbClassic.]

---

---

Discussion:

---

• Overrides, Overloads and Shadows confusion.

Perhaps it is too early to tell, or maybe it is just me.

Anyway, MicroSoft has chosen a strange implementation of VbDotNet's OO features. They have this new keyword Shadows which is related to the keyword Overloads (see VB.NET spec 4.3.3).

Shadows override by name, Overloads by signature. Shadows override all members of the same name, Overloads only the matching signature. One might think that if the name and signature is identical and appears only once, then there is no difference?

That is "of course" wrong. When you shadow an inherited member you actually have two members of the same name. The inherited one is accessible only through an interface higher in the class hierarchy, the implemented one is accessible only through the interface of the implementing class. I think this breaks polymorphism.

Worse is that Shadows is implied when no keywords are specified.

I really see no practical difference between Overrides, Overloads and Shadows, except that Shadows hides the member from higher classes. But with all these keywords there is a mix that rather contradict clarity than improve it:

1. If you override one member then you specify 'Overrides'.
2. If you override two or more overloaded members from the base class, then you specify 'Overloads'. The 'Overrides' usage is incorrect, Overloads in this case implies 'Overrides'.
3. The IDE tries to correct you, but gives rather dumb suggestions.
4. If the base forgets to declare its members with 'Overridable', derived classes still inherits these members, but can not override them.

The 'Shadows' keyword might come in handy some time, but not often enough to justify being implied/default. The other keywords mentioned is just noise. Make 'Overrides' equal to 'Overloads' and make them default, and there is no difference except cleaner and clearer code.

My preliminary conclusion is that VbDotNetIsaDisaster? to program in. I have always been satisfied with VB6, been looking forward to the OO improved version, but the disappointment forces me towards C# in the first place, perhaps to Delphi or Java.

For MicroSoft's sake I hope it is just me -- ThomasEyde

---

It seems to me that VB has always been targeted at inexperienced programmers who tend to write spaghetti no matter what you give them, and what makes them happy are features that save key strokes. I think this might be in that category. I think the general consensus has always been to use CsharpLanguage to do "real" DotNet development.

There is nothing wrong by itself with saving keystrokes. I personally feel that visual things are best done with a visual interface. However, not all things are that way and some things are not easy to maintain as a visual even if they are easy to start as a visual. It is a matter of PickTheRightToolForTheJob. -- AnonymousDonor

(new speaker) If that's the consensus I disagree with it. The language differences between CsharpLanguage and VisualBasicDotNet are so minor that it's hardly possible to say one is much better than another. The two are somewhat different syntaxes for what amounts to the same comprehensive DotNet language. -- MarkSchumann

---

Shadows lets you "fix" it if the base class forgot to declare it Overridable. Your method will be called instead of the base class method when the derived type is used or when type object is used (a reference of type Object binds by name at run time). It will not be used when passing a reference of the base class type.

Personally I find it of most use when I find it convenient to create a private member function of the same name of another private member function in the base class. Without Shadows, it thinks you are trying to override a non-overridable method.

This is just silliness to fix other silliness. Remeniscent of AddingEpicycles.

  Go read SomebodyElsesFramework

---

Perhaps allowing non-overridable methods are the problem to begin with. You never know what somebody will need in the future. Perhaps competing with Java was more important to MS than having a clean language. MS was paranoid of Java for several years. --top

---

---

• RE: Lack of C#(CsharpLanguage)-style auto-properties.

When we decide not to take advantage of the PropertyFieldTransparency property of the CsharpLanguage, the language designers thoughtfully provided us with the convenient syntactic shorthand notation enabled by "auto-properties."

In the CsharpLanguage, this code

    public int PriceCode { get; set; }

essentially generates this code for you at compile time

    private int _priceCode;
    public int PriceCode {
        get { return _priceCode; }
        set { _priceCode = value; }
    }

(which ends up producing results largely equivalent to writing this code)

    public int PriceCode;

(See PropertyFieldTransparency for details.)

But in VisualBasic, most pundits seem to think that VisualStudio Snippets and/or tools that generate all this duplicated code for you is the best solution. But CodeSnippetsEncourageDuplicatedCode! And other ways of generating boilerplate duplicated code do to.

---

CategoryVisualBasic CategoryDotNet