Perché il costrutto with () non è incluso in C #, quando è davvero interessante in VB.NET?

Question

Sono uno sviluppatore C #. Adoro la parentesi graffa perché vengo da C, C ++ e Java. Tuttavia, mi piacciono anche gli altri linguaggi di programmazione della famiglia .NET come VB.NET. Passare avanti e indietro tra C # e VB.NET non è poi un grosso problema se si sta programmando da tempo in .NET. Questo è un approccio molto comune nell'azienda in cui lavoro. Come tipo C #, mi piacciono molto le parole chiave letterale XML e con fornite dal compilatore VB.NET. Vorrei che Microsoft avesse incluso anche quelle funzionalità in C #.

Sono solo curioso di sapere cosa ne pensano gli altri sviluppatori!

Answer 1

Non sarei sorpreso se " Con " o una funzione simile viene aggiunta a C # eventualmente insieme ad altre funzionalità finora note di VB. Si è parlato molto nelle presentazioni di anteprima di C # 4.0 recentemente al PDC e altrove della maggiore attenzione alla parità linguistica. a partire da C # 4.0 e VB 10.

Answer 2

Personalmente non mi piace WITH quando viene usato dopo la costruzione - se dopo l'inizializzazione devi fare diverse cose con un oggetto, di solito quel comportamento dovrebbe essere incapsulato nel tipo stesso. Se vuoi davvero fare qualcosa come WITH, è solo una questione di dichiarare una variabile breve e, facoltativamente, introdurre un nuovo ambito.

Tuttavia, è utile essere in grado di inizializzare in modo compatto un oggetto con diverse proprietà - motivo per cui C # 3 ti permette di scrivere:

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

Esistono limitazioni a ciò (che i parametri opzionali e nominati in C # 4 aiuteranno a superare) ma è meglio di quanto non fosse senza portare a potenziali disordine / ambiguità.

(Sul fronte letterale XML, sono di nuovo con il team C # - XML ??è una tecnologia molto specifica da mettere in un linguaggio. Se potessero inventare un modulo generalizzato creare XML ma potrebbe essere usato anche per creare altri alberi, sarebbe bello, proprio come le espressioni di query non sono direttamente legate a IEnumerable o IQueryable.)

Answer 3

Puoi sostituire il With di VB.Net creando un rapido nome di variabile a una lettera. In realtà è meno codice, poiché With richiede anche un End With in seguito.

Ad esempio, una cosa che dovevo fare abbastanza spesso era iterare le righe in un datatable per un report di controllo / stile di interruzione.

In vb.net, potrebbe apparire così:

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

Il C # sarebbe simile a questo:

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);
}

La cosa da notare qui è che la versione C # in realtà aveva bisogno di meno digitazione, perché il VB non poteva combinare WITH con l'indice dell'array e doveva passare attraverso .Item proprietà per determinate cose. Non è un grosso problema qui, ma immagina se il rapporto avesse 20 campi invece di 2 e dovesse rompere su 3 elementi invece di 1.

Ovviamente, puoi usare la tecnica dimostrata in C # anche per VB. Ma la cosa principale da notare è che WITH non ti dà davvero molto.

Answer 4

Riguarda le preferenze degli sviluppatori, ma io sono con te per WITH. La mia preferenza è quella di ridurre al minimo il numero di variabili in gioco e l'ambito in cui vivono. La filosofia di C # sembra essere più o meno la stessa. Ma in questo caso le risposte qui sembrano suggerire che aggiungere (e rendersi responsabile di) una variabile è una buona cosa rispetto a un costrutto che, per me, è molto simile a lambdas.

Answer 5

Penso che sia piuttosto arbitrario consentire l'impostazione della proprietà 'di massa' solo durante l'inizializzazione. Davvero non capisco perché questo sarebbe "cattivo":

MyObj myObj = ObjFactoryFunction();

...

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

Sento che questo codice di esempio è pulito e conciso.

Answer 6

Di solito quando vedo una richiesta per una funzione con in C #, vedo codice che trarrebbe beneficio dal refactoring. Di solito quando il refactoring è terminato, la presunta necessità di con scompare.

Mi piace il modo in cui il mio codice funziona quando creo un'interfaccia fluida su un oggetto; ha alcune somiglianze con con . Se stavo progettando MessageBox.Show () , potrei scrivere:

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

Puoi anche vedere qualcosa di simile con Linq:

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

Sembra un po ' con ma sembra adattarsi naturalmente alla lingua che già ho.