C # 4 palabra clave dinámica - ¿por qué no?

Question

Después de leer muchas de las respuestas a En este hilo , veo que muchos de los que no les gusta citan el potencial de abuso de la nueva palabra clave. Mi pregunta es, ¿qué tipo de abuso? ¿Cómo podría abusarse de esto tan mal como para que a las personas les disguste con vehemencia? ¿Es solo sobre el purismo? ¿O hay un verdadero escollo que no estoy viendo?

Answer 1

Algunos lo ven como una herramienta que será abusada. Me gusta " Option Strict Off " y " Reanudar error siguiente " en VB que " puro " Lenguajes como C # y Java nunca han tenido.

Muchos dijeron lo mismo acerca de la " var " La palabra clave, sin embargo, no veo que se abuse de ella, una vez que se entendió que no era lo mismo que la "Variante" de VB

Se podría abusar en lugares donde los desarrolladores perezosos no quieren la verificación de tipos en las clases y solo intentan capturar llamadas dinámicas en lugar de escribir "si bla es bla ... " ;.

Personalmente, creo que podría usarse correctamente en situaciones como this reciente pregunta que he respondido.

Creo que los que realmente entienden su poder son aquellos que están muy involucrados en los lenguajes .NET dinámicos.

Answer 2

Creo que gran parte de la repulsión que las personas le están expresando a esta característica se reduce a " esta es una mala característica del lenguaje porque permitirá que los desarrolladores malos escriban código incorrecto. " Si lo piensas bien, según esa lógica, todas las características del idioma son malas.

Cuando me encuentro con un bloque de código de VB al que algunos genios han prefijado con On Error Resume Next , no soy VB el que maldigo. Tal vez debería, supongo. Pero en mi experiencia, una persona que está decidida a poner un centavo en la caja de fusibles encontrará un camino. Incluso si le vacías los bolsillos, él hará sus propios centavos.

Yo, estoy esperando una forma más útil de interoperación entre C # y Python. Estoy escribiendo más y más código que hace esto. La palabra clave dynamic no puede llegar lo suficientemente pronto para ese caso de uso en particular, porque la forma actual de hacerlo me hace sentir como un académico soviético en la década de 1950 que viaja a Occidente para una conferencia : hay una cantidad inmensa de reglas y trámites antes de que me vaya, estoy bastante seguro de que alguien me estará vigilando todo el tiempo que esté allí, y la mayoría de lo que recojo mientras esté allí me lo quitarán yo en la frontera cuando regrese.

Answer 3

dinámico es malo porque este tipo de código aparecerá por todas partes:

public dynamic Foo(dynamic other) {
  dynamic clone = other.Clone();
  clone.AssignData(this.Data);
  return clone ;
}

en lugar de:

public T Foo<T>(T other) where T: ICloneable, IAssignData{
    T clone = (T)other.Clone();
    clone.AssignData(this.Data);
    return clone;
}

El primero, no tiene información de tipo estático, no se comprueba el tiempo de compilación, no se documenta a sí mismo, no hay inferencia de tipo, por lo que las personas se verán obligadas a usar una referencia dinámica en el sitio de la llamada para almacenar el resultado, lo que lleva a una mayor pérdida de tipo , y todo esto baja en espiral.

Ya estoy empezando a temer a dinámica .

Editar : el peligro ha pasado (¡uf!) ... y no se ha abusado de la dinámica después de todo, no hay necesidad de votarme después de 3 años :)

Answer 4

¿El verdadero escollo? Grave falta de documentación. Toda la arquitectura de la aplicación existe en la mente de la persona (o personas) que la escribió. Al menos con la escritura fuerte, puede ver qué hace el objeto a través de su definición de clase. Con la escritura dinámica, debe inferir el significado de su uso, en el mejor de los casos. En el peor de los casos, NO TIENES IDEA cuál es el objeto. Es como programar todo en JavaScript. ACK!

Answer 5

Cuando las personas se den cuenta de que no obtienen un buen IntelliSense con dynamic , volverán a ser dynamic -happy a dynamic -cuando sea necesario-y- var -a cualquier otro momento.

Los propósitos de dynamic incluyen: la interoperabilidad con lenguajes dinámicos y plataformas como COM / C ++ y DLR / IronPython / IronRuby; así como convertir a C # en IronSmalltalkWithBraces con todo lo que implementa IDynamicObject .

Todos tendrán buenos tiempos. (A menos que necesite mantener el código que escribió otra persona).

Answer 6

Esto es algo así como hablar sobre cámaras públicas, seguro que pueden y serán mal utilizadas, pero también hay beneficios al tenerlas.

No hay ninguna razón por la que no pueda prohibir la " dinámica " palabra clave en su propia guía de codificación si no los necesita. ¿Entonces, cuál es el problema? Quiero decir, si quieres hacer locuras con el " dinámico " La palabra clave y pretender C # es el primo mutante de JavaScript, sea mi invitado. Solo mantén estos experimentos fuera de mi código base. ;)

Answer 7

FUD. Podría ser lo mejor desde el pan rebanado, pero toda la experiencia que he tenido con VB, JavaScript, etc., me trae escalofríos al saber que C # tendrá un enlace dinámico. Sé que podré verlo racionalmente en un futuro próximo y ver qué tan buena será la nueva función para permitir la interoperabilidad con lenguajes dinámicos. Pero tomará algún tiempo. Soy humano ok :-)

Answer 8

No veo una razón por la que la forma actual de invocar métodos de forma dinámica sea errónea:

Se requieren tres líneas para hacerlo, o puedes agregar un método de extensión en System.Object para que lo haga por ti:

class Program
{
    static void Main(string[] args)
    {
        var foo = new Foo();            
        Console.WriteLine(foo.Invoke("Hello","Jonathan"));
    }        
}

static class DynamicDispatchHelper
{
    static public object Invoke(this object ot, string methodName, params object[] args)
    {
        var t = ot.GetType();
        var m = t.GetMethod(methodName);
        return m.Invoke(ot, args);
    }
}

class Foo
{
    public string Hello(string name)
    {
        return ("Hello World, " + name);
    }
}