Se un metodo basato sull’interfaccia richiede che usi “dynamic” obbedisca ancora alle regole di risoluzione del metodo C #?

A quanto ho capito, ogni lingua può avere il proprio gestore dynamic , in modo che vengano applicate le regole appropriate. Non sono sicuro se quanto segue è corretto / errato; pensieri?

Scenario: due interfacce (una implementa l’altra) con alcuni metodi:

 public interface IA { void Bar(object o); } public interface IB : IA { void Foo(object o); } 

e un’implementazione di base:

 public class B : IB { public void Foo(object o) { Console.WriteLine("Foo"); } public void Bar(object o) { Console.WriteLine("Bar"); } } 

Ora, con normale C # (nessuna dynamic ), possiamo accedere ai metodi di IA da un target di tipo IB :

 IB b = new B(); var o = new { y = "z" }; b.Foo(oy); // fine b.Bar(oy); // fine 

Ora aggiungiamo deliberatamente un po ‘di dynamic agli argomenti, il che rende l’intero invoke utilizzare l’elaborazione dynamic (come nel caso generale, questo potrebbe avere un impatto sulla risoluzione del sovraccarico, anche se non sarà qui):

 IB b = new B(); dynamic x = new {y = "z"}; b.Foo(xy); // fine b.Bar(xy); // BOOM! 

Che non funziona con RuntimeBinderException :

‘IB’ non contiene una definizione per ‘Bar’

Ora, quello che dice è completamente corretto in quanto IB non ha un metodo Bar . Tuttavia, come illustrato nel primo esempio: in normali regole C # ci si aspetterebbe che dal momento che il tipo di dichiarazione del target sia un’interfaccia ( IB ), le altre interfacce note per essere implementate (cioè IA ) vengono controllate come parte della risoluzione di sovraccarico.

Quindi: questo è un bug? O lo sto fraintendendo?

Questa è una ben nota limitazione del raccoglitore, chiesto più volte a SO e al sobject di questo articolo di feedback . Citerò la risposta di Microsoft:

Questa era un’area che abbiamo esplicitamente escluso per il momento in cui spediamo C # 4.0 e ci piacerebbe rivisitare questo. Questo caso specifico di metodi ISet / IList che sono effettivamente definiti su ICollection è il luogo più visibile in cui non scavare attraverso le interfacce principali limita inutilmente la portata del binding dinamico in C #.

Speriamo di aggiungere presto questo tipo di supporto, anche se questo problema si trova attualmente al di sotto della nostra linea di riduzione dei bug. Stiamo segnalando che il problema non verrà risolto per indicare che al momento non stiamo eseguendo il monitoraggio per risolvere questo problema nella prossima versione di Visual Studio. Riattiveremo questo bug nel prossimo anno se otteniamo risultati superiori alle aspettative attraverso la nostra lista di triage di bug, o se rivisiteremo il bug per la seguente versione.

Che non è ancora successo, afaik. L’articolo non ha molti voti.