Globedia.com

×

Error de autenticación

Ha habido un problema a la hora de conectarse a la red social. Por favor intentalo de nuevo

Si el problema persiste, nos lo puedes decir AQUÍ

×
×
Recibir alertas

¿Quieres recibir una notificación por email cada vez que Demóstenes escriba una noticia?

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

23/04/2010 17:44 0 Comentarios Lectura: ( palabras)

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.


Sobre esta noticia

Autor:
Demóstenes (15 noticias)
Fuente:
algoritmosyobjetos.blogspot.com
Visitas:
4611
Licencia:
Copyright autor
¿Problemas con esta noticia?
×
Denunciar esta noticia por

Denunciar

Comentarios

Aún no hay comentarios en esta noticia.