Perché il costrutto with () non è incluso in C #, quando è davvero interessante in VB.NET?
-
07-07-2019 - |
Domanda
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!
Soluzione
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.
Altri suggerimenti
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.)
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.
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.
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.
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.