Eiffel: Void-safety. No más errores de null reference!!

Al momento de escribir el libro todavía no estaba implementado completamente el mecanismo que lograba void-safety en Eiffel. El problema que se evita es conocido como excepción por null reference o void call (según el lenguaje y entorno).
El problema se presentaba cuando se realiza una llamada de la forma: x.f(a)si  x era una referencia a Void (null reference). La tipificación estática no es suficiente, ya que ésta asegura (en el ejemplo anterior) que existe una feature f aplicable a x. Lo que garantizaría la void-safety es que en el momento de la ejecución haya un objeto asignado a x. En .Net este error es comúnmente encontrado mediante una excepción con el mensaje: "Object reference not set to an instance of an object". El mecanismo que logra evitar este problema esta completamente implementado a partir de EiffelStudio 6.4. 
Recordaran que en Eiffel existen dos clases de tipos: expandidos y de referencia. Con los primeros no hay problema por su propia semántica, siempre hay un objeto. El problema podría presentarse solamente con los tipos no expandidos. 
En resumen, lo que estamos diciendo, es que una entidad puede ser asiganda (attached) o  no asignada (detached) en este último caso es Void (null en otros lenguajes). Una llamada a una entidad no asignada provoca un error en tiempo de ejecución. Eiffel implementa un mecanismo para resolver este problema.
La asignación es vista (hasta ahora) cómo una propiedad en tiempo de ejecución, es decir una entidad en algún momento de la ejecución del programa puede estar asignada o no asignada. Para lograr la void-safety ampliamos este concepto de asignación para considerar también la asignación estática. Este último tipo de asignación puede ser evaluado en tiempo de compilación. El mecanismo implementado asegura que se cumpla una importante propiedad: la consistencia de asignación.


Consistencia de Asignación: si una entidad x es estáticamente asignada sus valores posibles en tiempo de ejecución son dinámicamente asignados.


Para garantizar entonces que no haya llamadas a void (void call) se incorpora al lenguaje la siguiente regla:


Regla de void-safety: Una llamada de la forma x.f(a) es permitida solamente si x es estáticamente asignada.


Al garantizar que x es estáticamente asignada, por la regla de la consistencia de la asignación x no puede asumir valores void en ninguna llamada.


Para garantizar la void-safety Eiffel utiliza una estrategia basada en tres mecanismos:

• Patrones de asignación certificados (Certified Attachment Patterns o CAPs), que básicamente representan esquemas de código que el compilador puede garantizar ser seguros.
• Tipos asignados. Son tipos que no pueden tener valores nulos (void). 
• Instrucción "Object Test". Esta instrucción permite a los programadores tratar de forma especial los valores nulos

En los siguientes artículos iremos describiendo cada uno de estos mecanismos en detalle.