estático/Compartido en VB.NET y C# visibility

Question

He enfrentado una situación en VB.NET y C# (.NET2) con la visibilidad de los miembros estáticos/compartidos. Me parece un poco extraño en VB.NET:

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

     public string Name { get { } } 
    } 

uso: A.Instance.Name // único nombre es "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 

uso:

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

// miembro compartido se comporta como una pública clase puedo repetirlo a infinito ..

es ésta una supervisión Microsoft o una "característica" VB.NET?

Answer 1

No es un descuido, pero su código VB dará activará una advertencia, lo que significa claramente: no use esta notación.

En VB, los miembros estáticos puede acceder a través de una instancia, ya que estrictamente hablando, VB no tiene static: VB tiene la palabra clave Shared, lo que significa que el miembro es compartieron entre todos los casos, como se se opone a static donde un miembro no pertenece a instancia.

Ahora bien, esta es una distinción semántica entre las palabras clave. Simplemente sucede que estas dos semánticas distintas tienden a tener exactamente el mismo efecto.

Por supuesto, static en C# que hoy es idéntica a Shared en VB.NET, pero su legado es diferente y de Shared VB simplemente tiene una historia diferente y, por tanto, históricamente un significado diferente. Con este sentido, se hace absolutamente sentido para acceder Shared miembros a través de una instancia.

También tiene sentido cuando se utiliza junto con Option Strict Off (tipificación suelto): aquí, que a veces no sabe tipo de una variable, pero todavía puede ser que desee acceder a un miembro Shared. Ahora, usted tiene más remedio que utilizar una instancia para acceder a ella:

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 

Answer 2

El compilador de C# no permitirá hacer referencia a una propiedad estática en una instancia de un objeto, sólo en el propio tipo. Esta es una restricción C# en lugar de .NET CLR. VB.NET permitirá esto pero advertirá en contra de esto.

Answer 3

Es una característica; Esto no es un error. VB está trabajando como está diseñado. Los diferentes idiomas toman diferentes decisiones sobre si un método estático se puede tratar como un método de una instancia o no. VB lo permite. C++ lo permite. C# no.

Recuerde, los criterios de diseño de diferentes idiomas son diferentes y, por lo tanto, las decisiones que se toman son diferentes.En el equipo de diseño de C#, valoramos mucho una definición de lenguaje que crea patrones ilegales que parecen sospechosos; ya que no hay que significa para pasar una instancia como el receptor a un método estático (a menos que el cálculo de la expresión del receptor cause un efecto secundario) entonces ¿por qué permitir que el usuario escriba código sin sentido?

En el equipo de diseño de VB, valoran el código que trabaja de la manera en que usted quiso que funcione la primera vez que lo escribió; si algo parece un poco dudoso, tal vez dar una advertencia, pero permitirlo y seguir adelante.

Si usted está interesado en algunas de las cuestiones más sutiles en el diseño de las llamadas estáticas en C#, aquí es una cuestión interesante:

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