Funzionalità C # o .Net da tagliare presupponendo che non sia necessaria una retrocompatibilità? [chiuso]

Qualsiasi prodotto o framework si evolve. Principalmente è fatto per soddisfare le esigenze dei suoi utenti, sfruttare nuove capacità di elaborazione e semplicemente migliorarlo. A volte l'obiettivo di progettazione principale cambia anche con il prodotto. Il framework C # o .net non fa eccezione. Come vediamo, l'attuale 4a versione è molto diversa rispetto alla prima. Ma la cosa viene come una barricata a questa evoluzione, compatibilità all'indietro.

Nella maggior parte dei framework / prodotti ci sono funzionalità che sarebbero state tagliate se non fosse necessario supportare la compatibilità con le versioni precedenti. Secondo te, quali sono queste funzionalità in C # /. Net?

Si prega di citare una funzione per risposta.

Metodi anonimi . Penso che tutti siano d'accordo sul fatto che la sintassi del metodo anonimo scelto per C # 2.0 sia pesante e goffa rispetto alla sintassi lambda che abbiamo aggiunto a C # 3.0. È profondamente spiacevole avere due sintassi quasi identiche per fare la stessa cosa.

Mi libererei delle collezioni non generiche. Sono un abominio ... e ci sono troppi casi in cui sto usando Linq e devo fare qualcosa del genere

var customObjects = container.CustomObjects.Cast<CustomObject>();

Ogni volta che devo farlo, una piccola parte della mia anima muore.

vuoto come tipo . Perché mai "void" è un tipo? Non ha istanze, non ha valori, non è possibile utilizzarlo come argomento di tipo generico, tipo di parametro formale, tipo locale, tipo di campo o tipo di proprietà. Non ha significato come tipo; piuttosto, è un dato di fatto sull'effetto che una chiamata di metodo ha sullo stack della macchina virtuale. Ma la macchina virtuale è proprio questo: una macchina virtuale. La macchina reale inserirà il valore restituito in un registro (in genere EAX su x86) e non influenzerà affatto lo stack! Vuoto come tipo è solo una cattiva idea dappertutto.

Peggio ancora: quando usato in un tipo di puntatore come in void*esso significa qualcosa di completamente diverso da quello che significa quando usato come tipo di ritorno. Ora significa "un puntatore a una posizione di archiviazione di tipo sconosciuto", che non ha nulla a che fare con il suo significato come "un metodo che non restituisce alcun valore".

Possiamo sostituire void*come tipo di puntatore con IntPtr. (E void**con IntPtr*e così via.) Possiamo sostituire void come tipo di ritorno con "Unit", un tipo che ha un singolo valore, vale a dire null. Un'implementazione del CLR potrebbe quindi decidere che una chiamata di funzione tipizzata dall'unità potrebbe ottimizzare l'utilizzo di registri o stack in modo appropriato, sapendo che il null che viene "restituito" può essere tranquillamente ignorato.

In un mondo simile non hai più bisogno di separati Func<A, R>e Action<T>delegati. Action<T>è giusto Func<T, Unit>.

L'affermazione vuota; . A rischio di errore, quasi sempre un errore di battitura, e non ti dà alcun significato aggiunto che non sia già espresso da {}.

Covarianza non sicura su array di tipo di riferimento . Con la covarianza di typesafe attiva IEnumerable<T>, almeno una parte della necessità di covarianza di array è andata via. (Se avessimo un'interfaccia di elenco di sola lettura covariante, non ne avremmo affatto bisogno.)

L'operatore plus unario . L'operatore meno utile di tutti i tempi. Se non avessimo dovuto tenerlo per compatibilità con le versioni precedenti, lo avrei eliminato in un batter d'occhio. Chi usa questa cosa, qualcuno?

(Chiarimento: l'operatore plus unario +xnon è l'operatore di preincremento ++x, non l'operatore postincremento x++e non l'operatore di aggiunta binaria x+y.)

Valori numerici predefiniti a double

Per la maggior parte delle app aziendali , decimalè comunque più appropriato ... o forse sarebbe meglio rimuovere l'idea di un valore predefinito e forzare lo sviluppatore a fare effettivamente la scelta.

(Quel "rimuovere il default" sarebbe appropriato per alcune altre cose, anche. Ad esempio, ho rinunciato a cercare di convincere tutti che le classi devono essere sigillati per impostazione predefinita, ma ho il sospetto che sia più facile convincere la gente che dovrebbero pensare su se la loro nuova classe debba essere sigillata o meno e renderla esplicita.)

Questa è più una linea guida che una caratteristica, ma penso che sia importante perché è già troppo radicata nella mente delle persone come la soluzione canonica e migliore:

Il modello ufficiale da implementare IDisposable.

È ingombrante e ci sono modi migliori .

Io so che ci sono grandi differenze tra le varie classi del timer. Ma non potremmo liberarcene uno o due, comunque?

Metodi e tipi di Arraye List<T>che sono diventati obsoleti con Linq, ad esempio:

• Array.TrueForAll può essere sostituito con Enumerable.All
• Array.FindAll può essere sostituito con Enumerable.Where
• List<T>.ConvertAll può essere sostituito con Enumerable.Select
• Predicate<T> può essere sostituito con Func<T, bool>
• Converter<T,R> può essere sostituito con Func<T, R>
• IComparer<T> davvero dovrebbe essere un delegato Func<T, T, int>

Delegati non generici Come le raccolte non generiche, i delegati non generici sono inutili ora che abbiamo le serie Func e Action. E avrei tagliato le varianti con tre parametri. Se hai più di tre parametri, crea una struttura e usala come singolo parametro. Dichiarare un delegato specifico per la gestione degli eventi non è molto ASCIUTTO.

asmx Web Services

Penso che al giorno d'oggi siano piuttosto obsoleti con WCF.

Winforms
Sarebbe bello non dover navigare tra due piattaforme desktop. WPF è dove stanno andando le cose, quindi è frustrante avere una ridondanza completa a livello di piattaforma.