¿El C# 4 permitirá "fundición dinámica"? Si no, ¿debería C# apoyarlo?

Question

No me refiero a fundición dinámica en el sentido de convertir una interfaz inferior o clase base en una clase más derivada, me refiero a tomar una definición de interfaz que he creado y luego convertir dinámicamente a esa interfaz un objeto diferente NO derivado desde esa interfaz, pero compatible con todas las llamadas.

Por ejemplo,

interface IMyInterface 
{ 
    bool Visible 
    { 
     get; 
    } 
} 

TextBox myTextBox = new TextBox(); 
IMyInterface i = (dynamic<IMyInterface>)myTextBox; 

Esto podría lograrse en tiempo de compilación para los tipos conocidos, y de tiempo de ejecución para las instancias declaradas con dinámica. La definición de interfaz es conocida, como es el tipo (en este ejemplo), por lo que el compilador puede determinar si el objeto admite las llamadas definidas por la interfaz y realizar alguna magia para que tengamos el molde.

Supongo que esto no es compatible con C# 4 (no pude encontrar una referencia), pero me gustaría saberlo con certeza. Y si no es así, me gustaría discutir si debe incluirse en una futura variante del lenguaje o no, y las razones a favor y en contra. Para mí, parece una buena adición para permitir un mayor polimorfismo en el código sin tener que crear tipos completamente nuevos para ajustar los tipos de marcos existentes.

actualización
Para que nadie me acuse de plagio, yo no era consciente de Jon Skeet having already proposed this. Sin embargo, es bueno saber que pensamos en una sintaxis muy similar, lo que sugiere que al menos podría ser intuitiva. Mientras tanto, "tener una idea original" permanece en mi lista de deseos para otro día.

Answer 1

Creo que Jon Skeet ha tenido una propuesta de este tipo (http://msmvps.com/blogs/jon_skeet/archive/2008/10/30/c-4-0-dynamic-lt-t-gt.aspx), pero hasta ahora, no he oído que C# 4.0 lo vaya a tener.

Answer 2

Creo que eso es problemático. Está introduciendo el acoplamiento entre dos clases que no están acopladas.

Tenga en cuenta el siguiente código.

public interface IFoo 
{ 
    int MethodA(); 
    int MethodB(); 
} 

public class Bar 
{ 
    int MethodA(); 
    int MethodB(); 
} 

public class SomeClass 
{ 
    int MethodFoo(IFoo someFoo); 
} 

¿Esto debería ser legal entonces?

int blah = someClass.MethodFoo((dynamic<IFoo>)bar); 

Se parece que debería ser legal, ya que el compilador debe ser capaz de escribir de forma dinámica barras como algo que implementa IFoo.

Sin embargo, en este punto está conectando IFoo y Bar a través de una llamada en una parte completamente separada de su código.

Si edita Bar porque ya no necesita MethodB, de repente someClass.MethodFood ya no funciona, aunque Bar e IFoo no están relacionados.

De la misma manera, si agrega MethodC() a IFoo, su código se romperá de nuevo, aunque IFoo y Bar aparentemente no están relacionados.

El hecho es que, aunque esto sería útil en casos selectos donde hay similitudes entre objetos que no controla, hay una razón por la que las interfaces deben estar explícitamente unidas a objetos, y la razón es para que el compilador puede garantizar que el objeto lo implemente.

Answer 3

No es necesario que C# lo admita, ya que se puede implementar muy limpiamente como biblioteca.

He visto tres o cuatro implementaciones por separado (comencé a escribir una antes de encontrarlas). Aquí es el tratamiento más completo que he visto:

http://bartdesmet.net/blogs/bart/archive/2008/11/10/introducing-the-c-ducktaper-bridging-the-dynamic-world-with-the-static-world.aspx

Probablemente será aún más fácil de poner en práctica una vez que el DLR está integrada en el tiempo de ejecución.

Dado que la clase contenedora/reenviadora de una interfaz determinada se puede generar una vez y almacenar en caché, y luego un objeto determinado de tipo desconocido se puede envolver una vez, hay muchas posibilidades de almacenar en caché los sitios de llamadas, etc. el rendimiento debe ser excelente. Por el contrario, creo que la palabra clave dynamic, que es una característica de lenguaje, y una muy compleja, es una digresión innecesaria y potencialmente desastrosa, con un lenguaje de cuerdas que anteriormente tenía una filosofía de tipado estático muy clara, que le dio una dirección obvia para la mejora futura. Deberían haber mantenido eso e hicieron que la inferencia tipo funcione mejor y mejor hasta que la escritura se volvió más invisible. Hay tantas áreas donde podrían evolucionar el lenguaje, sin romper los programas existentes, y sin embargo, no lo hacen, simplemente debido a limitaciones de recursos (por ejemplo, el motivo por el que var no se puede usar en más lugares es porque tendrían que reescribir el compilador y no tienen tiempo).

Todavía están haciendo cosas buenas en C# 4.0 (las características de varianza) pero hay mucho más que se puede hacer para que el sistema de tipo sea más inteligente, más automático y más potente para detectar problemas en tiempo de compilación. En cambio, básicamente estamos obteniendo un truco.

Answer 4

El marco de código abierto Impromptu-Interface hace esto usando el C# 4 y el dlr.

using ImpromptuInterface; 

interface IMyInterface 
{ 
    bool Visible 
    { 
     get; 
    } 
} 

TextBox myTextBox = new TextBox(); 
IMyInterface i = myTextBox.ActLike<IMyInterface>(); 

Puesto que utiliza el DLR También se trabajará con ExpandoObject y DynamicObject.