co- e controvarianza bug in .NET 4.0

Question

comportamenti strani con la co- e controvarianza sostegno C# 4.0:

using System; 

class Program { 
    static void Foo(object x) { } 
    static void Main() { 
    Action<string> action = _ => { }; 

    // C# 3.5 supports static co- and contravariant method groups 
    // conversions to delegates types, so this is perfectly legal: 
    action += Foo; 

    // since C# 4.0 much better supports co- and contravariance 
    // for interfaces and delegates, this is should be legal too: 
    action += new Action<object>(Foo); 
    } 
} 

risultati di con ArgumentException: Delegates must be of the same type.

Strano, non è vero? Perché Delegate.Combine() (che è stato chiamato quando si esegue l'operazione += sui delegati) non supporta la co- e la controvarianza in fase di esecuzione?

Inoltre, ho trovato che il tipo di delegato BCL System.EventHandler<TEventArgs> non ha annotazioni controvarianti sul suo parametro generico TEventArgs! Perché? È perfettamente legale, tipo TEventArgs utilizzato solo nella posizione di input. Forse non c'è un'annotazione controvariante perché nasconde bene il bug con lo Delegate.Combine()? ;)

p.s. Tutto ciò influenza il VS2010 RC e le versioni successive.

Answer 1

Per farla breve: la combinazione dei delegati è tutti incasinati rispetto alla varianza. L'abbiamo scoperto tardi nel ciclo. Stiamo lavorando con il team CLR per vedere se possiamo inventare un modo per far sì che tutti gli scenari comuni funzionino senza compromettere la compatibilità con le versioni precedenti, e così via, ma qualsiasi cosa creeremo non sarà probabilmente nella versione 4.0. Speriamo di risolvere tutto in un pacchetto di servizi. Mi scuso per l'inconveniente.

Answer 2

Covarianza e controvarianza specifica la relazione di ereditarietà tra tipi generici. Quando si ha controvarianza di covarianza &, le classi G<A> e G<B> possono trovarsi in una relazione di ereditarietà a seconda di cosa sia A e B. Puoi trarne vantaggio quando chiami metodi generici.

Tuttavia, il metodo Delegate.Combine non è generica e la documentation clearly says quando verrà generata l'eccezione:

ArgumentException - Sia un e b non sono null di riferimento (Nothing in Visual Basic), e a e b non sono istanze dello stesso tipo di delegato.

Ora, Action<object> e Action<string> sono certamente le istanze di un diverso tipo delegato (anche se correlato via relazione di ereditarietà), quindi in base alla documentazione, è un'eccezione. Sembra ragionevole che il metodo Delegate.Combine possa supportare questo scenario, ma questa è solo una possibile proposta (ovviamente questo non era necessario fino ad ora, perché non è possibile dichiarare delegati ereditati, quindi prima di co/contro-varianza, nessun delegato aveva alcuna relazione di ereditarietà) .

Answer 3

Una difficoltà con la combinazione di delegati è che, a meno che non si specifichi quale operando si suppone sia il sottotipo e che è supertipo, non è chiaro quale sia il tipo di risultato. È possibile scrivere una factory wrapper che convertirà qualsiasi delegato con un numero specificato di argomenti e pattern di byval/byref in un supertipo, ma chiamare più volte un factory di questo tipo con lo stesso delegato produrrà wrapper diversi (questo potrebbe causare il caos con cancellazione dell'evento). In alternativa, è possibile creare una versione di Delegato.Combinare che costringerebbe il delegato di destra al tipo del delegato di sinistra (come bonus, il ritorno non dovrebbe essere typecast), ma si dovrebbe scrivere una versione speciale di delegate.remove per affrontarlo.

Answer 4

Questa soluzione è stata originariamente pubblicata da cdhowie per la mia domanda: Delegate conversion breaks equality and unables to disconnect from event ma sembra risolvere il problema della covarianza e della contravarianza nel contesto dei delegati multicast.

è necessario prima un metodo di supporto:

public static class DelegateExtensions 
{ 
    public static Delegate ConvertTo(this Delegate self, Type type) 
    { 
     if (type == null) { throw new ArgumentNullException("type"); } 
     if (self == null) { return null; } 

     if (self.GetType() == type) 
      return self; 

     return Delegate.Combine(
      self.GetInvocationList() 
       .Select(i => Delegate.CreateDelegate(type, i.Target, i.Method)) 
       .ToArray()); 
    } 

    public static T ConvertTo<T>(this Delegate self) 
    { 
     return (T)(object)self.ConvertTo(typeof(T)); 
    } 
} 

Quando si dispone di un delegato:

public delegate MyEventHandler<in T>(T arg); 

Si può usare combinando delegati semplicemente convertendo un delegato che fare tipo desiderato:

MyEventHandler<MyClass> handler = null; 
handler += new MyEventHandler<MyClass>(c => Console.WriteLine(c)).ConvertTo<MyEventHandler<MyClass>>(); 
handler += new MyEventHandler<object>(c => Console.WriteLine(c)).ConvertTo<MyEventHandler<MyClass>>(); 

handler(new MyClass()); 

Supporta anche la disconnessione dall'evento allo stesso modo, utilizzandoMetodo. Diversamente dall'utilizzo di alcuni elenchi personalizzati di delegati, questa soluzione fornisce una sicurezza dei thread pronta all'uso.

completo del codice con alcuni campioni si possono trovare qui:? http://ideone.com/O6YcdI