lunes, 19 de abril de 2010

Object-Test y tipos asignados: Void.Safety en Eiffel

En un artículo anterior describimos el mecanismo de CAP utilizado para conseguir sistemas void-safety en Eiffel. Ahora describiremos las otras herramientas tipos asignados y la instrucción object test
Object test provee un mecanismo de identificación de tipos en tiempo de ejecución (reemplaza también a la construcción anterior de Eiffel llamada intento de asignación). Básicamente verifica que una referencia tenga asignado un objeto de un tipo determinado.  La sintaxis es la siguiente:

if  attached {T} exp as l then
 -- Operaciones sobre l
end

La expression attached {T} exp as l   es una expression logica (booleana) que es verdadera cuando exp es una referencia que tiene asignado un objeto conformante con el tipo T.   La nueva variable l con alcance en el if pasa a tener asignado el objeto denotado por exp.          
Entonces es seguro la siguiente secuencia:

if attached x as l then
   l.f (a)
end

Dado que f(a) se invoca sobre l y sólo cuando este tiene un asignado un objeto (el mismo que referencia x en el momento del test). En el ejemplo último, el tipo T es implícitamente el tipo estático de x. El uso de l es obligatorio para void-safety porque evita problemas en caso de que en un ambiente multihilo sea modificado el valor de exp.

El otro mecanismo que queda por ver el de tipos asignados. Este mecanismo es una extensión del sistema de tipo de Eiffel. Previamente cualquier variable de un tipo de referencia podía tener asignado void. Así todas las variables eran consideradas desasignables (detachables). Ahora el standard de Eiffel soporta tipos asignados (attached) o desasignables (detachables). Si una variable es declarada como attached entonces el compilador previene que dicha variable puede asignársele Void o asignarse alguna cosa que pueda ser void.

Ejemplos:
x: attached STRING

y: detachable STRING

En el primer caso la x siempre tendrá un objeto asignado y nunca podrá darse un error de null reference, mientras en el segundo caso a la y se le puede asignar Void y la garantía de void-safety debe proporcionarse por los otros medios mencionados.
Para garantizar este mecanismo hay reglas que el compilador debe asegurar. Por ejemplo es posible asignar x a y pero no y a x.
Es necesario utilizar un mecanismo de inicialización que prevenga que una variable de un tipo attached no sea asignada. Para casos como enteros o valores lógicos Eiffel ya proveía un mecanismo de inicialización (por ejemplo los enteros son inicializados en cero) Los tipos de referencia (detachables) son asignados con Void, pero esto no sirve para los tipos de referencia attached. Para resolver el problema se utiliza el concepto de variable propiamente iniciada (properly set) que significa que a la variable le fue dado un valor distinto de Void . Se usa la siguiente regla:

Regla de inicialización de tipos asignados:
Si un programa usa una variable en cierta posición una de las siguientes propiedades debe cumplirse:

  •  La variable es propiamente asignada en esa posición. Esto se aplica a ambos tipos de variables: atributos y variables locales de una rutina.
  • La variable es un atributo y es propiamente inicializada al final de todo procedimiento de creación de la clase.

De esta manera completamos una visión general de los mecanismos de Eiffel para lograr evitar el problema de la null-reference. Cabe indicar que el compilador o el entorno de desarrollo traen facilidades para ir incorporando estos mecanismos. Por ejemplo es posible configurar que todos los tipos sean attached o detachable por defecto.

No hay comentarios:

Publicar un comentario