PDF de programación - Tipado dinámico en C# .NET 4.0

Mario del Valle,
Miguel Katrib

plataforma.net

Tipado dinámico

en C# 4.0

En números anteriores, dotNetManía ha venido presentando algunas de
las novedades de programación que estarán presentes en .NET Frame-
work 4 y C# 4.0, como los parámetros nombrados y por omisión [1], la
varianza y contravarianza [2], o la programación por contratos [3]. En esta
entrega vamos a tratar la que tal vez sea la más controvertida y revolu-
cionaria de las novedades: el tipado dinámico (dynamic typing) [4].

Traición, dicen los más ortodoxos. Después de que
.NET ha alabado tanto la seguridad otorgada por
el tipado estático (static typing), que entre otros
beneficios permite dar soporte a una maravilla
como Intellisense, resulta que ahora nos salen con
eso de los tipos dinámicos, para posponer el con-
trol de tipos a tiempo de ejecución… ¿Y los ries-
gos que eso me va a introducir? Oportunismo,
dicen los detractores. ¿Me vienen a descubrir eso
ahora? Si ya lo teníamos con Python y con Java -
Script, lenguajes que no nos imponen la “camisa
de fuerza” del tipado estático…

Como en todo, los extremismos son malos. Lo
que sí puede decirse que no es estático es la volun-
tad de Microsoft de evolucionar, siempre con la
visión de potenciar y hacer más grata la labor de
los desarrolladores. En este mundo “dinámico”
coincidimos con los objetivos de .NET 4.0 de uni-
ficar paradigmas, ampliando el arsenal de recur-
sos para abordar los diferentes escenarios que cada
vez más se nos presentan.

Es cierto que hasta ahora en raras ocasiones
nos hemos encontrado con problemas que no
hayamos podido resolver con el tipado estático;
en todo caso, aderezando nuestros programas con
un poco de reflexión (reflection). Pero ya tenemos
Silverlight, y con éste la posibilidad de ejecutar
código .NET en el cliente Web; y ya que ahora
tenemos esa gran posibilidad, entonces debemos
facilitar la programación de ese código .NET, de
modo que las aplicaciones Web puedan lidiar en

tiempo de ejecución con tipos desconocidos, que
no se puedan prever estáticamente. De este modo,
ese código .NET podría entenderse con lo que ya
está por ahí hecho en la Web usando JavaScript u
otros lenguajes de script que son inherentemente
dinámicos.

Que sea estático lo que pueda ser
estático
Los ordenadores de hoy tienen esencialmente la
misma arquitectura que la de sus bisabuelos: pro-
cesador más memoria. En la memoria lo mismo se
ponen datos que instrucciones; todo depende de
cómo se le pide al hardware que interprete el con-
tenido de esa memoria. Pero el hardware no apor-
ta mucha protección: si mandamos a interpretar
como instrucción lo que realmente fue guardado
como dato, en el mejor de los casos se producirá
un error detectable si la representación de dicho
dato no se corresponde con el formato de una ins-
trucción. Por otro lado, si una operación de hard-
ware interpreta como dato lo que tenga la memo-
ria, el hardware verifica que el “dato” esté en el for-
mato adecuado, por ejemplo una representación
en punto flotante que corresponda a la aritmética,
o una dirección de memoria que sea accesible, y
poco más. Si el desarrollo de software ha llegado
hasta aquí, ha sido gracias a las capas de abstrac-
ción que han ido poniendo los lenguajes de pro-
gramación, los compiladores y los marcos de tra-

Miguel Katrib es doctor y
profesor jefe de programa-
ción del departamento de
Ciencia de la Computación
de la Universidad de La Ha-
bana. Miguel es líder del
grupo WEBOO, dedicado a
la orientación a objetos y la
programación en la Web. Es
entusiasta de .NET y miem-
bro del comité editorial de
dotNetManía.

Mario del Valle es licen-
ciado en Ciencia de la
Computación por la Uni-
versidad de La Habana, ins-
tructor de programación y
desa rro llador del grupo
WEBOO
www.weboomania.com.

bajo (frameworks) que se han ido sedi-
mentando con el pasar de los años, de
lo que .NET es un gran exponente.

Tipado estático es poder describir
en el código fuente que escribimos los
tipos que creamos y los tipos de nues-
tras entidades (variables, propiedades,
parámetros, tipos de retorno de las fun-
ciones, etc.) para que este texto sea
sometido a compilación. Como todo se
sabe, o se puede deducir a partir del tex-
to de los programas o de la información
de otros componentes ya compilados,
el compilador podrá detectar entonces
cualquier incongruencia en el uso ina-
decuado de los tipos y de las entidades
que se definen a partir de ellos. De este
modo, el código generado por la com-
pilación podrá ejecutarse con la segu-
ridad de que no se producirá un error
imprevisto causado por inconsistencia
en el uso de las operaciones o por inten-
tar aplicar una operación inexistente.
El paradigma de la Programación
Orientada a Objetos (POO) es un buen
ejemplo que propicia este tipado está-
tico. Si a partir del código fuente se pue-
de saber que x es una entidad de tipo A,
si un método M es aplicable al tipo A, si
el método M tiene un parámetro de tipo
B y si b es una entidad de tipo B, enton-
ces el compilador puede comprobar que
una llamada x.M(b) es correcta y gene-
rar un código que se ejecute con tran-
quilidad, sin tener que estar haciendo
comprobaciones en tiempo de ejecu-
ción. Por otro lado, una herramienta
como Intellisense podrá desplegar las
opciones de A (que incluyen el nombre
M) apenas tecleemos x..

.NET ha evolucionado haciendo
cada vez más flexible la forma de usar
estáticamente los tipos, porque en los
lenguajes de programación, a diferen-
cia que en la filosofía, el concepto de
estático no implica carencia de evolu-
ción1. Las jerarquías de tipos y el enla-
ce tardío (late binding), logrado en C#
a través de las interfaces y la redefini-
ción (override) de métodos virtuales, nos
aportan flexibilidad sin perder seguri-

dad. La genericidad nos permite definir
estáticamente patrones a partir de los cua-
les podemos definir nuevos tipos (ver [6]).
En C# 4.0 se continúa perfeccionando el
tipado estático con la varianza y la cova-
rianza (ver [2]), aportando aún más flexi-
bilidad.

Inferencia de tipos

Históricamente, para garantizar el
tipado estático, facilitarse el trabajo,
o hacer más legible la lectura huma-
na del código, muchos lenguajes y
compiladores han obligado a declarar
explícitamente las entidades. Sin
embargo, esto no es un requerimien-
to para que haya chequeo estático de
tipos (static type checking). Por ejem-
plo, en C# 3.0 [7, 8] podemos escri-
bir no solo int i = 2; sino también
var i = 2;. En el segundo caso, el
compilador infiere que el tipo de i es
int porque la parte derecha de la asig-
nación es de tipo int. Si esta fuera la
única diferencia, usted podría pre-
guntarse ¿dónde está la gracia de var?
Pero si analiza la siguiente sentencia
LINQ:

var films = from f in cineDB.Films

where f.Rating == 5
orderby f.Title
select new {

Title = f.Title,
Genre = f.Genre.Name,
Director = f.Director.Name

};

Comprenderá que sería un fastidio
tener que definir un tipo que exprese la
estructura de las tuplas resultantes, para
tener luego que declarar explícitamente
la variable films como de dicho tipo. En
definitiva, manipular tal tipo por su nom-
bre no es lo que interesa en esta situación,
sino saber que los valores resultantes de
la consulta disponen de las propiedades

<<

dnm.plataforma.net

Title, Genre y Director (y que, claro,
Intellisense nos las muestre). De este
modo, se puede escribir con confianza
estática:

foreach (var f in films)

Console.WriteLine("{0,‐24} {1,15} ({2})",

f.Title,
f.Genre.Name,
f.Director.Name);

En el ejemplo anterior de LINQ no
es que no haya tipado estático, sino que
el compilador infiere el tipo formado
en la cláusula select y asignado a la
variable films. La inferencia de tipos
es una característica de muchos len-
guajes funcionales que erróneamente
lleva a algunos a decir que éstos no tie-
nen tipado estático. De hecho, F# (que
con su inclusión en Visual Studio 2010
ya ha sido reconocido como hijo legí-
timo de la familia .NET) es un lengua-
je funcional que tiene inferencia de
tipos (aunque no prescinde totalmente
de la declaración estática, cuando es
conveniente hacer más legibles o via-
bles algunas situaciones)2.

Si inferir los tipos es mejor que indi-
carlos explícitamente o viceversa es, a
fin de cuentas, un problema de gusto
sintáctico. Pero lo que no debe dejar
dudas es que en ambos casos hay tipa-
do estático; el tipo está ahí, más o menos
evidente, pero ahí en el texto, es cono-
cido en tiempo de compilación, y por
tanto nada imprevisible ocurrirá duran-
te la ejecución.

Recordamos a un físico que
defendía a FORTRAN vs. Pascal, no
porque su aritmética fuese más eficien-
te sino “porque no le obligaba a decla-
rar las variables”. El compilador de
FORTRAN lo que hacía era inferir el
tipo de las variables según la letra con
la que empezara su nombre. Hay pro-
gramadores que defienden a Python
sólo porque se quitan de encima lo que

1 Lo que algunos detractores del tipado estático no saben o no quieren reconocer.
2 dotNetManía está en deuda con algunos lectores que nos han reclamado que escribamos sobre F#. Esperamos hacerlo en próximas entregas.

a
í
n
a
M
t
e
N
t
o
d

<
<

15

<<

dnm.plataforma.net

para ellos es “la camisa de fuerza del
tipado estático”3.

Pero libertad no es libertinaje. Abo-
gamos porque todo lo que pueda defi-
nirse estáticamente se defina estática-
mente, aprovechando todas las flexibi-
lidades y recursos que nos ha ido ofre-
ciendo .NET y su familia de lenguajes.
Los llamados lenguajes dinámicos
son aquellos que ofrecen recursos que
permiten operaciones estáticamente no
verificables sobre datos para los cuales
no se tiene un tipo estáticamente cono-
cido en el contexto en que se aplican
dichas operaciones. .NET 4.0 y C# 4.0
han incluido la posibilidad de tener tipa-
do dinámico.

El tipo dynamic
El código a continuación es un ejem-
plo de lo que ahora podemos tener en
C# 4.0 sin que el compilador proteste:

dynamic d = DevolverObjetoDeTipoDesconocido();
d.M();

La variable local