var
se escribe estática - el compilador y el tiempo de ejecución saben el tipo - que acaba de ahorrar algo de tecleo ... los siguientes son 100% idénticos:
var s = "abc";
Console.WriteLine(s.Length);
y
string s = "abc";
Console.WriteLine(s.Length);
Todo lo que sucedió fue que el compilador descubrió que s
debe ser una cadena (desde el inicializador). En ambos casos, sabe (en la IL) que s.Length
significa la propiedad (instancia) string.Length
.
dynamic
es un muy diferente bestia; es muy similar a object
, pero con distribución dinámica:
dynamic s = "abc";
Console.WriteLine(s.Length);
Aquí, s
se escribe tan dinámico. No sabe acerca de string.Length
, porque no sabe nada sobre s
en tiempo de compilación. Por ejemplo, la siguiente sería compilar (pero no de ejecución) también:
dynamic s = "abc";
Console.WriteLine(s.FlibbleBananaSnowball);
En tiempo de ejecución (solamente), lo haría cheque para la propiedad FlibbleBananaSnowball
- no logran encontrarlo, y explotar en una lluvia de chispas.
Con dynamic
, las propiedades/métodos/operadores/etc se resuelven en el tiempo de ejecución, en función del objeto real. Muy útil para hablar con COM (que puede tener propiedades solo de tiempo de ejecución), DLR u otros sistemas dinámicos, como javascript
.
Si tan sólo pudiera dar otro 1 para la propiedad FlibbleBananaSnowball ... :-) – Joey
Una cuestión interesante sería si hay ancestros dinámicos de clases declaradas estáticamente. Ejemplo: clase X {public int Y {get; set;}} dynamic (X) s = GetSpecialX(); Llamada prueba de cadena = s.Y; generaría un error de compilación porque el compilador conoce Y pero string test2 = s.Z compilaría bien y se verificaría en tiempo de ejecución. ¡Podría pensar en mucho valor de tales clases semidinámicas! – mmmmmmmm
@rstevens - IIRC, puede agregar comportamiento dinámico a través de una interfaz (aunque no hay soporte de lenguaje directo para implementar tipos dinámicos en C#, solo consumiéndolos), así que esto no es poco realista ... oh, la diversión que podríamos tener; -p –