Generici C#: senza limiti inferiori per progettazione?

Question

Stavo leggendo un'intervista con Joshua Bloch in Coders at Work, dove si lamentava dell'introduzione di generici in Java 5. Non gli piace l'implementazione specifica, in gran parte perché il supporto della varianza, i caratteri jolly di Java, lo rende inutilmente complesso.

Per quanto ne so, C# 3 non ha nulla come i caratteri jolly espliciti, limitati, ad es. non è possibile dichiarare un metodo PriceBatch che richiede una raccolta di asset o qualsiasi sottoclasse di asset (void PriceBatch(Collection<? extends Asset> assets) in Java?).

Qualcuno sa perché i caratteri jolly e i limiti non sono stati aggiunti a C#? Queste funzioni sono state intenzionalmente tralasciate per rendere più semplice la lingua, oppure è qualcosa che non sono ancora state in grado di implementare?

MODIFICA: Santo fumo, commenti da Eric Lippert stesso! Dopo aver letto le sue e le osservazioni penetranti di Paolo, mi rendo conto che almeno sono supportati limiti superiori e che l'esempio di cui sopra può essere tradotto in C# come:

void PriceBatch<T>(ICollection<T> assets) where T : Asset 

limiti più bassi, d'altra parte, sono a quanto pare non supportato come Eric dice nel suo secondo commento, ad es probabilmente non c'è modo di tradurre direttamente questo (un po 'forzato) codice Java in C#:

public class Asset {} 
public class Derivative extends Asset {} 
public class VanillaOption extends Derivative {} 

public static <T extends Asset> void copyAssets(Collection<T> src, Collection<? super T> dst) { 
    for(T asset : src) dst.add(asset); 
} 

Collection<VanillaOption> src = new ArrayList<VanillaOption>(); 
[...] 
Collection<Derivative> dst = new ArrayList<Derivative>(); 
[...] 
copyAssets(src, dst); 

Sono corretto? Se questo è il caso, c'è un motivo particolare per cui C# ha limiti superiori ma non inferiori?

Answer 1

Una domanda complicata.

Prima consideriamo la tua domanda fondamentale, "perché questo è illegale in C#?"

class C<T> where T : Mammal {} // legal 
class D<T> where Giraffe : T {} // illegal 

Cioè, un tipo di vincolo generico può dire 'T deve essere qualsiasi tipo di riferimento che può essere assegnato ad una variabile di tipo Mammifero', ma non" T deve essere qualsiasi tipo di riferimento, una variabile di cui potrebbe essere assegnata una giraffa ".Perché la differenza?

Non so. Questo è stato molto tempo prima che il mio tempo sul team C#. La risposta banale è" perché il CLR non lo supporta ", ma la squadra quello progettato C# generics era lo stesso team che ha progettato generici CLR, quindi non è molto di una spiegazione

La mia ipotesi sarebbe semplicemente che come sempre, per essere supportata, una funzionalità deve essere progettata, implementata, testata, documentata e spedita ai clienti; nessuno ha mai fatto nessuna di queste cose per questa funzione, e quindi non è nella lingua. Non vedo un grande vantaggio per la funzionalità proposta; le caratteristiche complicate senza vantaggi convincenti tendono ad essere tagliate qui.

Tuttavia, questa è una supposizione. La prossima volta mi capita di chiacchierare con i ragazzi che hanno lavorato con i generici - vivono in Inghilterra, quindi non è come se fossero in fondo a me, purtroppo - chiederò.

Per quanto riguarda il tuo esempio specifico, penso che Paul sia corretto. Non hai bisogno di vincoli di limite inferiore per farlo funzionare in C#. Si potrebbe dire:

void Copy<T, U>(Collection<T> src, Collection<U> dst) where T : U 
{ 
    foreach(T item in src) dst.Add(item); 
} 

Cioè, mettere il vincolo su T, non su U.

Answer 2

C# 4 introduce nuove funzionalità che consentono la covarianza e la contravarianza nei generici.

Ci sono altri SO post che parlare di questo in modo più dettagliato: How is Generic Covariance & Contra-variance Implemented in C# 4.0?

La nuova funzione non attiva automaticamente in tutti i tipi, ma c'è una nuova sintassi che permette agli sviluppatori di specificare se gli argomenti generici sono covariante o controverso.

Le versioni C# precedenti a C# 4 avevano funzionalità limitate simili a questa in quanto riguardano delegati e determinati tipi di array. Per quanto riguarda i delegati, i delegati che accettano tipi di parametri di base sono consentiti. Per quanto riguarda i tipi di array, penso che sia valido a meno che non ci sia il pugilato coinvolto. Cioè, una matrice di clienti può essere il caso di una matrice di oggetti. Tuttavia, non è possibile eseguire il cast di una matrice di int in una matrice di oggetti.

Answer 3

NET ha già l'equivalente di caratteri jolly, più logicamente chiamati vincoli di tipo generico, si può fare ciò che si descrive senza problemi

namespace ConsoleApplication3 
{ 
    class Program 
    { 
     static void Main(string[] args) 
     { 
     List<a> a = new List<a>(); 
     List<b> b = new List<b>(); 
     List<c> c = new List<c>(); 
     test(a); 
     test(b); 
     test(c); 

     } 

     static void test<T>(List<T> a) where T : a 
     { 
      return; 
     } 
    } 
    class a 
    { 

    } 
    class b : a 
    { 

    } 
    class c : b 
    { 

    } 
} 

Esempio 2

namespace ConsoleApplication3 
{ 
    class Program 
    { 
     static void Main(string[] args) 
     { 
      ICollection<VanillaOption> src = new List<VanillaOption>(); 
     ICollection<Derivative> dst = new List<Derivative>(); 
     copyAssets(src, dst); 
     } 

     public static void copyAssets<T,G>(ICollection<T> src, ICollection<G> dst) where T : G { 
      foreach(T asset in src) 
       dst.Add(asset); 
     } 
    } 
    public class Asset {} 
    public class Derivative : Asset {} 
    public class VanillaOption : Derivative {} 
} 

Questo esempio rappresenta una conversione del codice dal tuo esempio in java.

Non sono davvero in grado di rispondere alla domanda vera!