static/Shared in VB.NET and C# visibility

Question

I have faced with a situation in VB.NET and C# (.NET2) with the visibility of the static/shared members. It seems to me a little strange in VB.NET:

    public class A 
    {
        private static A instance;
        public static A Instance 
        {
            get { return instance; }
        }

        public string Name { get { } }
    }

usage: A.Instance.Name // ONLY Name is "visible"

---

VB.NET:

Public Class A
  Private Shared _instance As A

  Public Shared ReadOnly Property Instance() As A
    Get
      Return _instance
    End Get
  End Property


  Public ReadOnly Property Name() As String
    Get
      Return ""
    End Get
  End Property

End Class

usage:

A.Instance.Instance.Instance.Instance...

// shared member behaves like a class public one I can repeat it to infinite..

is this a Microsoft oversight or a VB.NET "feature"?

Answer 1

The C# compiler won't allow you to reference a static property on an instance of an object, only on the type itself. This is a C# rather than a .NET CLR restriction. VB.NET will allow this but will warn against it.

Answer 2

It is a feature; this is not a bug. VB is working as designed. Different languages make different choices about whether a static method can be treated as a method of an instance or not. VB allows it. C++ allows it. C# does not.

Remember, the design criteria of different languages are different, and therefore the decisions made are different. On the C# design team, we highly value a language definition which makes illegal patterns that look suspicious; since there's no meaning to passing an instance as the receiver to a static method (unless computing the receiver expression causes a side effect) then why allow the user to type meaningless code?

On the VB design team, they value the code working the way you meant it to work the the first time you typed it; if something looks a bit dodgy, maybe give a warning, but allow it and move on.

If you're interested in some of the more subtle issues in the design of static calls in C#, here's an interesting issue:

http://blogs.msdn.com/ericlippert/archive/2009/07/06/color-color.aspx

Answer 3

It's not an oversight but your VB code will trigger a warning, which plainly means: do not use this notation.

In VB, static members can be accessed via an instance, since strictly speaking, VB doesn’t have static: VB has the keyword Shared, meaning that the member is shared between all instances, as opposed to static where a member doesn’t belong to any instance.

Now, this is a semantical distinction between those keywords. It just so happens that these two distinct semantics tend to have the exact same effect.

Of course, static in C# is today identical to Shared in VB.NET but their legacy is different and VB’s Shared simply has a different history and therefore historically a different meaning. With this meaning, it makes absolutely sense to access Shared members via an instance.

It also makes sense when used together with Option Strict Off (loose typing): here, you sometimes don’t know a variable’s type but you still might want to access a Shared member. Now, you’ve got no choice but to use an instance to access it:

Option Strict Off
' … '
Dim o As Object = New A()
' Somewhere else, we want to access a static member of A but we don’t know A: '
Dim instance = o.Instance