¿Por qué la construcción with () no está incluida en C #, cuando es realmente genial en VB.NET?

Question

Soy desarrollador de C #. Realmente me encantan las llaves porque vengo de C, C ++ y Java. Sin embargo, también me gustan los otros lenguajes de programación de la familia .NET, como VB.NET. Cambiar de un lado a otro entre C # y VB.NET no es realmente tan importante si ha estado programando durante un tiempo en .NET. Ese es un enfoque muy común en la empresa donde trabajo. Como chico de C #, me gusta mucho el literal XML y las palabras clave with proporcionadas por el compilador VB.NET. Ojalá Microsoft hubiera incluido esas características en C # también.

Tengo curiosidad, ¡qué otro desarrollador tiene que decir al respecto!

Answer 1

No me sorprendería si " Con " o una característica similar se agrega a C # eventualmente junto con otras características exclusivas hasta ahora exclusivas de VB. Recientemente se habló mucho en las presentaciones preliminares de C # 4.0 en PDC y en otros lugares sobre el creciente "enfoque en la paridad del lenguaje". comenzando con C # 4.0 y VB 10.

Answer 2

Personalmente, no me gusta WITH cuando se usa después de la construcción; si necesita hacer varias cosas con un objeto después de que se inicializa, por lo general, ese comportamiento debe encapsularse en el tipo en sí. Si realmente quieres hacer algo como WITH, solo es cuestión de declarar una variable corta y, opcionalmente, introducir un nuevo alcance.

Sin embargo, es útil para poder inicializar de forma compacta un objeto con varias propiedades, razón por la cual C # 3 le permite escribir:

MyObject x = new MyObject { Name="Fred", Age=20, Salary=15000 };

Hay limitaciones para esto (que los parámetros opcionales y nombrados en C # 4 ayudarán a superar), pero es mejor de lo que era sin generar problemas / ambigüedades potenciales.

(En el frente literal de XML, estoy nuevamente con el equipo de C #: XML es una tecnología muy específica para poner en un lenguaje. Si pudieran llegar a un formulario generalizado que sucedió a crear XML, pero también podría usarse para crear otros árboles, eso sería bueno, así como las expresiones de consulta no están directamente vinculadas a IEnumerable o IQueryable).

Answer 3

Puede reemplazar el de VB.Net con creando un nombre rápido de variable de una letra. En realidad, es menos código, ya que With también requiere un End With más adelante.

Por ejemplo, una cosa que solía hacer con bastante frecuencia era iterar sobre las filas en una tabla de datos para un informe de estilo de control / interrupción.

En vb.net, podría verse así:

Dim CurCustomerName As String 
Dim CustomerSalesTotal As Decimal

Dim ds As DataSet = GetReportData()
With ds.Tables(0).Rows
   Dim i As Integer = 0
   While i < .Count
       ''//{
       CurCustomerName = .Item(i)("CustName")
       CustomerSalesTotal = 0
       PrintHeaderLine(CurCustomerName)

       While i < .Count AndAlso CurCustomerName = .Item(i)("CustName")
            ''//{
            PrintItemLine(.Item(i)("OrderTotal"))
            CustomerSalesTotal += .Item(i)("OrderTotal")

            i+= 1
       End While ''//}
       PrintSubTotalLine(CustomerSalesTotal)
   End While ''//}
End With

El C # se vería así:

string CurCustomerName;
Decimal CustomerSalesTotal;

DataSet ds = GetReportData();
DataRowCollection r = ds.Tables[0].Rows;
int i=0;
while (i<r.Count)
{
    CurCustomerName = r[i]["CustName"];
    CustomerSalesTotal = 0;
    PrintHeaderLine(CurCustomerName);

    while (i<r.Count && CurCustomerName == r[i]["CustName"])
    {
        PrintItemLine(r[i]["OrderTotal"]);
        CustomerSalesTotal += r[i]["OrderTotal"];

        i++;
    }
    PrintSubTotalLine(CustomerSalesTotal);
}

Lo que hay que notar aquí es que la versión C # realmente necesitaba menos tipeo, porque el VB no podía combinar WITH con el índice de la matriz, y tenía que pasar por el .Item propiedad para ciertas cosas. No es un gran problema aquí, pero imagínese si el informe tuviera 20 campos en lugar de 2 y tuviera que dividir 3 elementos en lugar de 1.

Por supuesto, también podría usar la técnica demostrada en C # para VB. Pero lo principal a tener en cuenta es que WITH realmente no te da mucho.

Answer 4

Se trata de las preferencias del desarrollador, pero estoy contigo sobre WITH. Mi preferencia es minimizar el número de variables en juego y el alcance dentro del cual viven. La filosofía de C # parece ser muy parecida. Pero en este caso, las respuestas aquí parecen sugerir que agregar (y hacerse responsable de) una variable es algo bueno en comparación con una construcción que, para mí, es muy similar a las lambdas.

Answer 5

Creo que es bastante arbitrario permitir solo la configuración de propiedades 'masivas' durante la inicialización. Realmente no entiendo por qué esto sería 'malo':

MyObj myObj = ObjFactoryFunction();

...

if(someCondition)
  myObj { Prop1 = 1, Prop2 = 2 };

Siento que este código de ejemplo es limpio y conciso.

Answer 6

Por lo general, cuando veo una solicitud de una función with en C #, veo un código que se beneficiaría de la refactorización. Por lo general, cuando se realiza la refactorización, la supuesta necesidad de con desaparece.

Me gusta la forma en que funciona mi código cuando construyo una interfaz fluida en un objeto; Tiene algunas similitudes con con . Si estaba diseñando MessageBox.Show () , podría escribir:

new MessageBox()
    .SetText("Hello World!")
    .SetButtons(MessageBox.Buttons.OK)
    .SetIcon(MessageBox.Icon.Information)
    .Show();

También puedes ver algo similar con Linq:

var q = Enumerable.Range(1, 100)
            .Where(x => x % 2 == 0)
            .Select(x => x * x);

Se siente un poco como con pero parece encajar naturalmente en el idioma que ya tengo.