¿Por qué las propiedades automáticas de C# no son compatibles con valores predeterminados como VB 2010?

Question

Al observar las nuevas características de VB 2010, me encontré con el soporte para Auto-Implemented Properties.

Desde que estoy trabajando con C#, esto parecía muy familiar, pero me di cuenta de que VB no añadir una característica que me gustaría tener en C#: establecer un valor por defecto arbitraria de la propiedad de auto-aplicado:

Public Class Person 

    Property Name As String = "Scott Guthrie" 
    Property Age as Integer = 35 

End Class 

Me gusta mucho el uso limpio de auto-propiedades en C#. Esto nos ahorraría el esfuerzo de introducir un campo de respaldo y conectarlo a la propiedad cada vez que simplemente necesitamos un valor predeterminado, lo que complicaría innecesariamente el código.

Me preguntaba por qué esto no se introdujo también en C#? ¿Cuál podría ser la razón para no hacer esto? ¿Está en curso una discusión de sintaxis o hay limitaciones técnicas para implementar esto?

Answer 1

¿Qué hay de

:

public class Person 
{ 
    public Person() 
    { 
     this.Name = "Scott Guthrie"; 
     this.Age = 35; 
    } 
    public string Name { get; set; } 
    public string Age { get; set; } 
} 

en la práctica, que se reduce a lo mismo y no es que mucho trabajo extra, creo. Pero tal vez, por una vez en mucho tiempo, VB se ve más claro a continuación, C# ... ;-)

EDITAR (lógica):
que estabas preguntando por la razón en su último comentario bajo (y en) su pregunta original Pensando en voz alta, creo que el principio en C# que el código de inicialización va a un lugar y un solo lugar, es decir, el constructor, es el motivo de esta decisión. Agregar otro lugar donde tenga que buscar el código de inicialización hace que la depuración sea más difícil y el código menos claro.

Obviamente, un valor de inicialización en línea no puede contener otras inicializaciones o cálculos (al menos, muy limitados). Si bien estoy de acuerdo en que puede ser más conciso en la forma de VB, entendería que el equipo de C# y Anders Hejlsberg si dicen que consideran una mayor ventaja tener un lugar para la inicialización.

EDITAR:here's what Microsoft says about it. En resumen, no para C# 4.0, ¿pero quizás para C# 5.0? También:

"No es tan fácil como parece: la siguiente cosa que queremos es que la constructor para inicializar el campo respaldo , pero sólo puede hacerlo a través de el organismo, el cual podría no ser lo que desea."

y (sólo un comentarista):

"La falta de inicialización o constructor de control hace que la función de prácticamente sin valor para las propiedades que regresan un tipo de referencia"

.

Answer 2

¿Por qué no solo los predetermina en el constructor? Para eso es también.

Answer 3

Si bien no soy Microsoft, sugeriría que el beneficio percibido era menor que el costo de implementar, probar y dar soporte a la función.

Por supuesto, usted podría establecer los valores por defecto al declarar un constructor, pero estoy de acuerdo que la sintaxis de VB es un poco más claro (sobre todo si vas a decorar con metadatos, como <DefaultValue(...)>)

Answer 4

Tengo una solución para el tedioso negocio de convertir una propiedad de auto en un campo de propiedad con respaldo: Mi complemento , AtomineerUtils hará esa refactorización con una sola pulsación de tecla.