C# Perché non è possibile aprire i tipi generici come parametri?

Question

Perché non è possibile aprire i tipi generici come parametri. Ho spesso classi come:

public class Example<T> where T: BaseClass 
{ 
    public int a {get; set;} 
    public List<T> mylist {get; set;} 
} 

Diciamo che BaseClass è come segue;

public BaseClass 
{ 
    public int num; 
} 

Allora voglio un metodo di dire:

public int MyArbitarySumMethod(Example example)//This won't compile Example not closed 
{ 
    int sum = 0; 
    foreach(BaseClass i in example.myList)//myList being infered as an IEnumerable 
     sum += i.num; 
    sum = sum * example.a; 
    return sum; 
} 

Poi ho dovuto scrivere un'interfaccia solo per passare questo una classe come parametro come segue:

public interface IExample 
{ 
public int a {get; set;} 
public IEnumerable<BaseClass> myIEnum {get;} 
} 

il generico la classe deve essere modificata in:

public class Example<T>: IExample where T: BaseClass 
{ 
    public int a {get; set;} 
    public List<T> mylist {get; set;} 
    public IEnumerable<BaseClass> myIEnum {get {return myList;} } 
} 

Questo è un sacco di cerimonie per quello che avrei pensato che il compilatore potesse dedurre. Anche se qualcosa non può essere cambiato, trovo psicologicamente molto utile se conosco le ragioni/giustificazioni per l'assenza di scorciatoie di sintassi.

Answer 1

Sono stato in una situazione simile, ma non ho mai avuto questa (molto buona!) Domanda. Ora che sono costretto a pensare a questo proposito, ecco la mia risposta:

Si prevede che il seguente al lavoro:

void F(Example<> e) { 
    Console.WriteLine(e.a); //could work 
} 

Sì, questo potrebbe teoricamente lavorare, ma questo non lo farà:

void F(Example<> e) { 
    Console.WriteLine(e.mylist); //?? type unknown 
} 

Si aspetta che il compilatore e il CLR siano in grado di analizzare i corpi del metodo e dimostrare che nel primo caso non è possibile un accesso davvero non sicuro. Che potrebbe essere fatto funzionare. Perché non è stato? Probabilmente, il design non è davvero sano e confuso. Inoltre, "tutte le funzionalità non sono implementate per impostazione predefinita. Qualcuno deve implementarle, testarle e documentarle".

Modifica: desidero sottolineare che questa funzione non può essere implementata senza la collaborazione del CLR. Il compilatore C# deve emettere il metodo esatto da chiamare che non è possibile su un tipo generico aperto. Il sistema di tipi non ammette nemmeno una tale variabile in questo momento.

Answer 2

Un razionale di implementazione: supportare ciò richiederebbe che tutti i metodi di classe generici non privati ​​siano resi virtuali, altrimenti non sarebbe possibile conoscere quale metodo specifico richiedere un tipo generico "aperto". Esistono diversi jittings dei diversi metodi di tipo chiuso, con diversi indicatori di metodo corrispondenti. Definire un'interfaccia manualmente corrisponde a istruire il compilatore quali metodi devono essere trattati come virtuali e consente inoltre di specificare esattamente quale sottoinsieme della funzionalità "aperta" che si desidera esporre. Quello che stai proponendo è fondamentalmente che tutte le classi generiche hanno una classe di interfaccia generata implicitamente per la porzione "aperta" della loro interfaccia pubblica, che ha implicazioni di prestazioni per la classe anche se questa funzione non viene mai utilizzata.

Answer 3

Forse non sono comprendere la vostra domanda esatta, ma si può fare il vostro "MyArbitrarySumMethod" fare un esempio arbitrario dichiarando in questo modo:

public int MyArbitarySumMethod<T>(Example<T> example) where T : BaseClass 

È quindi possibile chiamare senza specificare "T":

int sum = MyArbitrarySumMethod(myExampleInstance); 

È quello che stai cercando?