¿Por qué debe una propiedad de implementación en VB.NET tener especificadores 'ReadOnly' que coincidan?

Question

las siguientes obras en C#:

interface I 
{ 
    int X { get; } 
} 

class C : I 
{ 
    public int X 
    { 
     get { ... } 
     set { ... } 
    } 
} 

El siguiente no funciona en VB.NET:

Interface I 
    ReadOnly Property X As Integer 
End Interface 

Class C 
    Implements I 

    Public Property X As Integer Implements I.X 
     Get 
      ... 
     End Get 
     Set(value As Integer) 
      ... 
     End Set 
    End Property 
End Class 

El mensaje de error Implementing property must have matching 'ReadOnly' or 'WriteOnly' specifiers es bastante explica por sí mismo, así que saben lo que está mal aquí. Tampoco es un gran problema, porque es bastante fácil evitar esta limitación.

Tengo curiosidad, sin embargo: ¿Alguien sabe por qué los diseñadores de VB decidieron tratar este caso de manera diferente que en C#?

Answer 1

no estoy seguro sobre el lado VB, pero con la implementación de interfaz explícita de IX en C# También se obtendría una queja sobre el colocador añadido:

interface I 
{ 
    int X { get; } 
} 

class C : I 
{ 
    int I.X // explicit implementation of I.X 
    { 
     get { return 1; } 
     set { } 
    } 
} 

se obtiene un error similar en C# . Para la VB, puede que desee revisar este hilo SO: If an interface defines a ReadOnly Property, how can an implementer provide the Setter to this property?

Answer 2

Tienes ReadOnly de la Propiedad en el Interface I pero no en el heredada Class C por lo que las firmas de propiedad no coinciden, por lo tanto, el error. Estoy seguro de que no puede agregar un acceso set a una propiedad ReadOnly también.

Answer 3

Debe proporcionar una propiedad de solo lectura para implementar I.X; si quieres YourClass.X a ser una propiedad de lectura-escritura, entonces el que implementa IX debería usar otro nombre de sólo lectura (por ejemplo

 
    Public Property Xreadonly As Integer Implements I.X 

No estoy seguro de por qué .Net requiere el uso de tres tipos de propiedades (solo lectura, solo escritura y lectura y escritura), en lugar de simplemente permitir que un objeto que declara una propiedad de solo lectura y una propiedad de solo escritura se use como si tuviera una propiedad de lectura-escritura, pero sí. Tal vez sea porque querían asegurarse de que una anulación de un getter seguiría la misma ruta de herencia que una anulación de un setter, pero parece que hay casos en los que sería más útil considerar getters y setters como elementos separados (en algunos casos, por ejemplo, puede ser útil tener un método Get de propiedad que devuelva un tipo que sea distinto de, pero coercible para, el Establecer tipo de método; o puede ser útil tener múltiples sobrecargas de Set; ninguno está permitido en .net, sin embargo).