Archive for December, 2007
C# 3.0
Para estructurar el código de manera más organizada y sobre todo para poder utilizar extension methods estoy escribiendo el código en C# 3.0. Puede parece algo extraño porque no es demasiado utilizado aún, pero hay partes del framework que no serían nada útiles sin los extension methods. No es mayor problema ya que desde hace bastante tiempo el compilador de mono (mcs/gmcs/smcs) soporta gran parte de C# 3.0 y la última versión ya lo soporta casi todo. La versión de la máquina virtual implementada por Microsoft que los soporta ya hace tiempo que está disponible como descarga para windows y Visual Studio 2008 (en la calle desde el 19 de noviembre de 2007) también permite elegir la versión del lenguaje para la que compilar (incluyendo la 3.0).
No obstante los usuarios finales ni siquiera necesitan instalar una de las últimas versiones de la máquina virtual de .NET (CLR) porque los binarios generados son compatibles con la versión 2.0 ya que las características añadidas a C# 3.0 son sólamente syntactic sugar, aunque quienes quieran utilizar estas funciones añadidas al .NET Framework en sus programas necesitarán una versión actual que lo soporte.
Como ya he comentado, ya principal razón de compilar para C# 3.0 es poder utilizar extension methods, que nos permitirán añadir funciones muy útiles a las clases ya existentes del .NET Framework sin necesidad de reescribir las clases ni sustituir las librerías, por ejemplo podremos hacer “byte a=5; a.Getbit(3);” para obtener el tercer bit de la representación binaria del valor de la variable “a”. Me hubiese gustado poder hacer lo mismo utilizando indizadores, por ejemplo: “byte a=5; a[3];” lo que nos permitiría leer y modificar bits independientes de manera mucho más cómoda. C# 3.0 no soporta extensiones de indizadores ni propiedades pero se espera que C# 4.0 sí lo haga.
Pautas de desarrollo
Antes de que se una cualquier otro desarrollador quiero terminar la estructura principal del proyecto, sobre todo del compilador y el framework, porque son decisiones de diseño y no de implementación, y ese tipo de decisiones prefiero hacerlas sólo ya que de otra manera es mucho más fácil que acabemos discutiendo. Para el final del concurso espero tener terminado el diseño global de compilador y framework, y de momento acabo de terminar las pautas de desarrollo (en inglés) que indican a grandes rasgos cómo se debe escribir el código, más que nada para que sea lo más legible, usable y portable posible, aunque no es demasiado pedante y da bastante libertad al desarrollador.
Supongo que la regla más “incómoda” sea la de documentar casi todo el código fuente con comentarios XML, y documentar absolutamente todas las clases, métodos y variables públicas del framework. Esto es así porque aunque la documentación “real” cueste escribirla, los comentarios en XML son muy útiles para entender el código, y sobre todo el código del framework que va a ser utilizado por los usuarios finales para escribir sus propios programas para microcontroladores. No puedo permitir que un usuario normal quiera utilizar alguna clase incluída en pigmeo-framework y no tenga ni la más mínima idea de cómo utilizarlo. Obligando a los desarrolladores de pigmeo a escribir comentarios XML me aseguro de que cuando un usuario escriba código fuente y su entorno de desarrollo le autocomplete el nombre y los parmámetros de las funciones y variables estos usuarios vean claramente una pequeña descripción de lo que van a utilizar. No hay nada más incómodo que utilizar librerías sin documentar.
