1. casa
  2. Domanda e risposta
  3. E i parametri del tipo generico facoltativo in C# 5.0?

E i parametri del tipo generico facoltativo in C# 5.0?

2010-03-29 8 views
8

Solo un pensiero.E i parametri del tipo generico facoltativo in C# 5.0?

Non sarebbe utile avere parametri di tipo opzionali in C#?

Ciò renderebbe la vita più semplice. Sono stanco di avere più classi con lo stesso nome, ma diversi parametri di tipo. Inoltre VS non supporta questo molto Vell (i nomi dei file) :-)

Questo sarebbe per esempio eliminare la necessità di un IEnumerable non generica:

interface IEnumerable<out T=object>{ 
    IEnumerator<T> GetEnumerator() 
}

Cosa ne pensi?

fonte

2010-03-29 Lars Corneliussen

+0

Nel tuo esempio come distinguere tra 'IEnumerable ' e 'IEnumerable'? Il primo sarebbe 'IEnumerable <>'? –

+0

typeof (IEnumerable ) == typeof (IEnumerable) == typeof (IEnumerable <>). MakeGenericOrSo (typeof (oggetto)) –

+0

La soluzione standard qui intorno al problema del nome del file, e penso una sanzionata dal team VS (anche se al momento non riesco a trovare un collegamento), è quello di salvare il file per AGenericType con un nome come AGenericType'4.cs. –

risposta

3

Sono decisamente per questo.

Attualmente sto scrivendo metodi di supporto per diversi scenari in cui voglio passare riferimenti a membri diversi e metodi di classi. Per fare ciò sto prendendo, per esempio, uno Expression<Func<TIn, TOut>> come argomento per l'helper (che mi consente di raggiungere il metodo con un'espressione lambda, mantenendo così tutto fortemente digitato).

BUT - Attualmente ho bisogno di definire un nuovo metodo di supporto per ogni diverso numero di argomenti di input, dal momento che ho bisogno di avere una quantità diversa di argomenti generici ad esso.Invece di

HelperMethod<TIn>(Expression<Action<TIn>> arg) // Yes, C# can distinguish 
HelperMethod<TOut>(Expression<Func<TOut>> arg) // these two from eachother 
HelperMethod<TIn, TOut>(Expression<Func<TIn, TOut>> arg) 
HelperMethod<TIn1, TIn2, TOut>(Expression<Func<TIn1, TIn2, TOut>> arg) 
// etc

ho potuto fare che fare con, al massimo, due metodi:

HelperMethod<TIn>(Expression<Action<TIn>> arg) 
HelperMethod<TOut, TIn1 = DummyType, ...>(Expression<Func<TIn1, ..., TOut> arg)

Nel mio caso, sarebbe evitare un sacco di duplicazione del codice ...

fonte

2010-04-09 23:38:06

2

Quale sarebbe l'uso principale per questa funzione di lingua? Vedo che potrebbe essere d'aiuto con alcune attività amministrative come i nomi dei file e meno la digitazione e altro, ma oltre a ciò non vedo quanto sarebbe utile.

Inoltre, questa funzione complicherebbe in modo significativo qualsiasi vincolo generico che potrebbe essere inserito sul parametro di tipo generico e il tipo predefinito stesso dovrebbe funzionare come una sorta di vincolo generico stesso.

Penso che questo complicherebbe la lingua senza offrire alcun vantaggio reale allo sviluppatore.

fonte

2010-03-29 22:38:13

+1

Manterrebbe più pulito il tipo hiearchie. Dato un A e B : A , B: A deriverebbe dallo stesso tipo di B –

+0

Il tipo predefinito sarebbe soggetto a tutti i vincoli in modo che il codice successivo possa rimanere ignorante. Fondamentalmente renderebbe IEnumerable uguale a IEnumerable (ad esempio, l'utilità reale della funzione è fornita con un'architettura più complessa) –

0

Non mi è chiaro cosa stiate esattamente proponendo. Attualmente ci possono essere tipi con lo stesso nome ma diversi parametri di tipo, ma che non sono correlati in alcun modo per ereditarietà - cosa farebbe allora la tua proposta?

Inoltre, se la libreria di classi di base è stata riprogettata da zero, quasi certamente non ci sarebbe un'interfaccia IEnumerable non generica - esiste solo perché il CLR non supportava i generici quando l'interfaccia è stata introdotta, e il generico l'interfaccia eredita da esso solo in modo che il codice legacy continui a funzionare. Le classi appena dichiarate vengono create per un CLR che supporta i generici, in modo che il problema non sia più rilevante.

fonte

2010-03-30 14:00:50 kvb

0

Recentemente mi sono imbattuto in un caso che avrebbe potuto usare qualcosa di simile, semplicemente non del tutto. Avevo un metodo che esegue una trasformazione di sorta, tra la classe A e la classe associata AChild e la classe B e la classe BChild. Di solito, la coppia A/AChild era la stessa di B/BCild, ma a volte A era una classe base di B e AChild una classe base di BChild.

Sarebbe stato bello poter dire che il mio parametro di tipo TB era impostato su TA e che TBChild era impostato su TAChild.

Si noti che questa era una situazione in cui era necessario scrivere i parametri del tipo, poiché l'inferenza non avrebbe funzionato.

fonte

2010-04-03 13:56:53

Problemi correlati

 Problemi correlati