Quali funzionalità di C# verrebbero rimosse se la retrocompatibilità non fosse un problema?

La retrocompatibilità è una grande preoccupazione per i progettisti di linguaggi, specialmente quando la lingua è popolare come C#. Nel tempo le lingue accumulano funzionalità obsolete. È considerata una buona pratica evitare queste funzionalità, ma sono mantenute nella lingua per compatibilità con le vecchie versioni.Quali funzionalità di C# verrebbero rimosse se la retrocompatibilità non fosse un problema?

Quali funzionalità del linguaggio o librerie di classi base in C# devono essere rimosse se la compatibilità con le versioni precedenti non rappresenta un problema?

Non sto chiedendo informazioni sulle funzionalità che alcuni sviluppatori amano e altri detestano. Sono interessato a caratteristiche che sono (più o meno) universalmente considerate come meglio evitate (forse perché ora c'è un modo decisamente migliore di fare la stessa cosa).

fonte

2009-11-04 ctford

Che ne dici di GOTO? Come in GOTO "soggettivo e argomentativo"? –

C'è un modo per perfezionare la domanda che soddisferà chi la vuole chiusa? Mi rendo conto che ciò che caratterizza il linguaggio di ogni sviluppatore è soggettivo, ma penso che ci siano alcune cose che sono quasi universalmente considerate cattive. – ctford

Non sono sicuro di quale sia il punto al di là di un "dibattito", voto a chiusura soggettiva e argomentativa. – user7116

ArrayList.

Non ha senso usarlo più. L'elenco <> è molto meglio.

fonte

2009-11-04 18:20:55 Reshure

Questa non è una funzionalità C#, è una classe BCL, ma sono d'accordo. – configurator

Tranne quelle rare occasioni in cui potresti effettivamente voler memorizzare un elenco di diversi tipi di oggetti. – Chris

Stiamo parlando di funzionalità C# o tipi nel BCL? ArrayList è nel secondo, ma la domanda riguarda il primo sembra. –

La classe ReaderWriterLock è praticamente inutile ora a favore della classe ReaderWriterLockSlim, che Microsoft stesso afferma is recommended for all new development.

fonte

2009-11-04 18:38:49

Solo un pignolo: come altri esempi, questo ha a che fare con la libreria .Net, non con C# stesso. –

@Neil: È interessante notare che nella mia risposta iniziale l'ho indicato, ma per qualche motivo è stato misteriosamente modificato. –

So che questa è una risposta ovvia ma qualsiasi classe, proprietà o metodo contrassegnato con l'attributo [Obsolete] sarà probabilmente il primo a essere rimosso.

fonte

2009-11-04 18:41:07

a meno che non sia contrassegnato come [Reincarnate (true)] –

-18

Elenchi generici (come menzionato da Reshure) incluso "var". Sono un sostenitore della dichiarazione esplicita di variabili.

Edit: Penso che le persone stiano equipaggiando "elenchi generici" con "generici". Se preferisci, "raccolte non tipizzate" come Hashtable o ArrayList.

fonte

2009-11-04 18:43:47

var è di tipo inferenza e non è direttamente correlato ai generici. È abbastanza richiesto per linq e aiuta a ridurre le dichiarazioni di tipo inutili-verbose (anche se è aperto all'abuso). In ogni caso, non verrebbe rimosso dalla lingua ... – Lee

Liste generiche ??? Inoltre non è perché non ti piace una funzionalità che dovrebbe essere rimosso. –

Yeesh. Sono tutto per tutto ciò che rende il mio C# meno simile all'HTML. – aehiilrs

-2

Dal BCL di:

interoperabilità COM
StringCollection (elenco generico)
StringDictionary (Dizionario generico)

fonte

2009-11-04 18:44:09 Dominiek

Non chiamerei COM Interop qualcosa che si riferiva esclusivamente alla "retrocompatibilità". C'è un sacco di * nuovi * sviluppi nativi là fuori. Cioè l'interop è un pezzo importante per questo interop, anche quando non si usa affatto la COM. –

Uso StringCollection durante la serializzazione di raccolte di stringhe per le impostazioni dell'app utilizzando la funzionalità Impostazioni di Visual Studio/.NET Framework. – jasonh

Ho sentito molti dei C# designer dire che si rammaricano fare matrici covariant.

fonte

2009-11-04 18:45:09

+1 Come spiegato molto bene qui: http://blogs.msdn.com/ericlippert/archive/2009/09/24/why-is-covariance-of-value-typed-arrays-inconsistent.aspx – jpbochi

Tipi non sigillati per impostazione predefinita.

fonte

2009-11-04 18:57:28 JaredPar

Il campo System.IO.Path.InvalidPathChars. Usarlo comporta un rischio per la sicurezza, ma non c'è nulla che possano fare al riguardo per ragioni di compatibilità.

fonte

2009-11-04 19:01:21

fonte o articolo su questo? – corymathews

In caso di implementazione di IEnumerable<T>, è necessario implementare e System.Collections.IEnumerator GetEnumerator() per motivi di compatibilità con le versioni precedenti.

fonte

2009-11-04 20:12:51 Mez

Infatti, non è solo per ragioni di compatibilità con le versioni precedenti. Deve essere lì per supportare l'enumerazione di qualsiasi oggetto "IEnumerable" indipendentemente dal suo tipo. – jpbochi

Parametri del costruttore di attributi con nome.

Attualmente, è possibile impostare i parametri denominati con:

[AttributeUsage(AttributeTargets.Method, Inherited = false, AllowMultiple = true)]

Questo è dai tempi di C# 1, ma ora ci sono i costruttori di oggetti:

new Foo(explicit, values) { Implicit = value }

che comporterebbe il seguente Costruttore di attributi:

[AttributeUsage(AttributeTargets.Method) { Inherited = false, AllowMultiple = true }]

fonte

2009-11-04 20:22:30 Dykam

Quali funzionalità di C# verrebbero rimosse se la retrocompatibilità non fosse un problema?

risposta

Problemi correlati