ES2230900T3 - Referencia de un procedimiento en un programa basado en objetos. - Google Patents
Referencia de un procedimiento en un programa basado en objetos.Info
- Publication number
- ES2230900T3 ES2230900T3 ES99955342T ES99955342T ES2230900T3 ES 2230900 T3 ES2230900 T3 ES 2230900T3 ES 99955342 T ES99955342 T ES 99955342T ES 99955342 T ES99955342 T ES 99955342T ES 2230900 T3 ES2230900 T3 ES 2230900T3
- Authority
- ES
- Spain
- Prior art keywords
- class
- delegate
- addition
- instance
- computer
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Lifetime
Links
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/44—Arrangements for executing specific programs
- G06F9/448—Execution paradigms, e.g. implementations of programming paradigms
- G06F9/4488—Object-oriented
- G06F9/449—Object-oriented method invocation or resolution
Landscapes
- Engineering & Computer Science (AREA)
- Software Systems (AREA)
- Theoretical Computer Science (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Stored Programmes (AREA)
- Devices For Executing Special Programs (AREA)
Abstract
Un producto de programa de ordenador basado en objetos, que comprende un código de programa de ordenador, realizado en una forma legible por ordenador, sobre un portador físico (22; 24; 26; 28), en el cual el código fuente del programa causa que un ordenador (20) lleve a cabo las etapas de representar una instancia y un primer método de una clase por medio de un valor delegado, que puede asignarse a variables y transferirse desde un procedimiento a otro, y de invocar al primer método llamando a un segundo método de una instancia de una clase, utilizando el valor delegado, en el cual los parámetros proporcionados al segundo método se proporcionan al primer método, y la lista de parámetros del segundo método coincide con la lista de parámetros del primer método; y en el cual, además, el primer método es identificado por nombre y por la coincidencia de la lista de parámetros y del tipo del resultado del primer método con la lista de parámetros y el tipo de resultado declarado para la clase.
Description
Referencia de un procedimiento en un programa
basado en objetos.
Esta invención se refiere generalmente a los
lenguajes de ordenador y, más en particular, a un método y un
dispositivo para programar en lenguajes basados en objetos u
orientados a objetos.
Los lenguajes de programación de alto nivel
permiten a los desarrolladores descomponer el código fuente en
trozos más pequeños. En lenguajes no orientados a objetos, la
unidad más pequeña de descomposición es un procedimiento o función.
En lenguajes orientados a objetos, la unidad más pequeña de
descomposición es, típicamente, un método en una clase.
Muchos lenguajes de programación modernos también
tienen mecanismos que permiten a los desarrolladores tratar estas
unidades de descomposición como valores, que pueden utilizarse como
valores (transferirse, almacenarse en estructuras de datos, etc.) y
también emplearse para "llamar" o "invocar" al trozo de
código que el valor representa. Lenguajes distintos proporcionan
mecanismos distintos.
En los lenguajes de programación no orientados a
objetos, la mejor conocida de estas estructuras es el puntero de
función hallado en C y C++. En los lenguajes de programación
funcionales (LISP, ML, Scheme, etc.) este estilo de programación es
común. En los lenguajes de programación orientados a objetos no se
ha desarrollado ningún mecanismo adecuado con este fin.
A fin de que un sistema de programación (lenguaje
y entorno de tiempo de ejecución) pueda permitir a los
desarrolladores crear y utilizar referencias a métodos, la presente
invención aborda los siguientes objetivos de diseño:
- a)
- definir una entidad que defina la forma del método al cual referirse;
- b)
- obtener una referencia a un método;
- c)
- almacenar esta referencia en estructuras de datos arbitrarias;
- d)
- transferir la referencia a código escrito por otros;
- e)
- permitir la invocación del método a cualquiera que tenga la referencia al método; y
- f)
- permitir a quien tenga una referencia al método determinar el objeto y el método de destino a los cuales se refiere.
Además, el sistema de programación de la presente
invención logra los objetivos precedentes en un entorno de tipos de
datos fuertes, haciendo posible que:
- a)
- los desarrolladores conozcan antes los problemas de falta de coincidencia de tipos (en tiempo de compilación), y no después (en tiempo de ejecución), y
- b)
- las herramientas de desarrollo presenten información a los desarrolladores acerca de la forma de los componentes que utilizan delegados.
Diversos productos emplean punteros de función a
la manera de C y C++, tales como el Visual C++, el Visual Basic y
el Visual Basic A de Microsoft®, todos ellos disponibles en la
Corporación Microsoft. La Interfaz de Programación de Aplicaciones
de Windows® hace también un extenso uso de punteros de función. Los
punteros de función de esta índole son deficientes, por diversas
razones:
- a)
- no ofrecen protección con respecto a los tipos, y producen asignaciones forzadas de tipos;
- b)
- no disponen de seguridad - un puntero de función es sólo un puntero, que puede ser alterado inadvertidamente e invocado luego, produciendo una caída del sistema; y
- c)
- no permiten acceder al objeto y método de destino.
Java VM de Microsoft® y los productos asociados
tienen un sistema "Reflejo del Núcleo de Java" que proporciona
una forma primitiva de referencia a métodos. Un desarrollador puede
obtener una instancia de java.lang.reflect.Method. Esta forma de
referencia es de enlace tardío inherente y, por lo tanto,
ineficiente.
Según un aspecto de la presente invención, se
proporciona un producto de programa de ordenador según la
reivindicación 1.
Según otro aspecto de la presente invención, se
proporciona un sistema de programación basado en objetos, según la
reivindicación 8.
Según un aspecto adicional de la presente
invención, se proporciona un método para programar un ordenador
según la reivindicación 19.
La Figura 1 ilustra un diagrama en bloques de los
principales componentes de la presente invención.
La Figura 2 ilustra las plataformas y soportes de
distribución aplicables a la presente invención.
La Figura 3 es un ejemplo de programa de
ordenador en J++ según la presente invención.
Las Figuras 4 y 5A ilustran ejemplos de
declaraciones de un delegado de enlace temprano, según la presente
invención.
La Figura 5B ilustra un ejemplo de construcción
de un delegado de enlace tardío, basado en un nombre de método de
tipo cadena de caracteres.
La Figura 6 es un ejemplo de definición de la
clase Delegate según la presente invención.
La Figura 7 es un ejemplo de definición de la
clase DelegateMulticast.
La Figura 8 ilustra un ejemplo de realización que
extiende el Visual J++ de Microsoft® para incluir una interfaz
com.ms.lang.Callable.
La Figura 9 ilustra un ejemplo de clase de
sucesos según la presente invención.
La Figura 10 ilustra un ejemplo de código de
procesamiento de sucesos según la presente invención.
La Figura 11 ilustra un ejemplo de código de
procesamiento de sucesos según la presente invención.
La Figura 12 ilustra un ejemplo de código de
procesamiento de sucesos según la presente invención.
La Figura 13 ilustra un ejemplo de código de
procesamiento de sucesos según la presente invención.
Las Figuras 14A - 14B ilustran un ejemplo de
programa de procesamiento de sucesos que emplea delegados según la
presente invención.
Las Figuras 15A - 15B ilustran un ejemplo de
programa de procesamiento de sucesos según la presente
invención.
La Figura 16 ilustra un ejemplo de un programa de
procesamiento de sucesos según la presente invención.
La Figura 17 ilustra una definición de la clase
Event según la presente invención.
La Figura 18 ilustra un ejemplo de definición de
una declaración de un procesador de sucesos según la presente
invención.
La Figura 19 ilustra un ejemplo de definición de
una clase CancelEvent según la presente invención.
La Figura 20 ilustra una declaración de un
procesador de sucesos según la presente invención.
En la siguiente descripción detallada de las
realizaciones preferidas, se hace referencia a los dibujos
adjuntos, que forman parte de la misma, y en los cuales se
muestran, a manera de ilustración, realizaciones específicas en las
cuales la invención puede ponerse en práctica. Se entiende que
pueden utilizarse otras realizaciones y efectuarse cambios
estructurales sin apartarse del campo de la presente invención.
La presente invención proporciona un mecanismo,
denominado aquí un "delegado", para referirse a un método en
la programación basada en objetos. Mientras que un puntero de
función contiene una referencia a una función, un delegado contiene
una referencia a un método. Los dos difieren en que un puntero de
función contiene sólo una referencia (una función), mientras que un
delegado contiene una referencia a un objeto y un método de ese
objeto.
Una propiedad útil de un delegado, según se
describe aquí, es que el delegado no conoce, ni le importa, el tipo
(clase) del objeto al que se refiere. En cambio, todo lo que
importa es que la lista de parámetros del método referenciado sea
compatible con el delegado. Esto hace que los delegados sean
bastante útiles para el empleo de notificación "anónima" - un
llamador que invoca a un delegado no necesita saber exactamente qué
clase o miembro está siendo invocado.
De forma similar a un puntero de función, un
delegado es un valor. Como otros valores, puede ser asignado a
variables, transferido desde un procedimiento a otro, etc. Un
delegado también puede ser empleado / aplicado / llamado. Cero o
más argumentos pueden transferirse al delegado al realizar esta
operación.
Los delegados difieren de los punteros de función
en que los delegados pueden ser de tipos protegidos, o fuertes.
Además, mientras que los punteros de función son independientes del
contexto - cuando una función es invocada a través de un puntero de
función, esta función no tiene más contexto que el transferido a
través de los parámetros -, un delegado lleva el contexto consigo.
Cuando se invoca un método a través del delegado, la invocación
tiene lugar sobre el objeto referenciado por el delegado y, de esta
manera, proporciona al método un contexto conocido.
Como se describirá más en detalle más adelante,
la invención toma múltiples formas distintas, según se ilustra en
la Figura 1. Como se muestra allí, el ejemplo de realización de los
delegados descritos aquí está realizado en forma de un lenguaje de
programación 10, un programa de ordenador 12, un compilador 14,
software intérprete 16 de Java VM y un modelo de sucesos 18. Como se
ilustra en la Figura 2, estas diversas realizaciones pueden
ejecutarse sobre un sistema informático 20 (que incluye componentes
informáticos convencionales tales como, pero no limitados a, una
CPU [Unidad Central de Proceso], almacenamiento, memoria, teclado,
ratón); por ejemplo, pero no como limitación, un ordenador personal
compatible con IBM; y almacenarse o realizarse de otra manera, en
una forma interpretable por una máquina, en diversos medios de
distribución, tales como controladores de discos rígidos 22,
disquetes 24, cederrones 26, o como una transmisión electrónica de
datos 28.
Ejemplo de realización de la
invención en
J++
El siguiente ejemplo de realización de la
invención describe una implementación de delegados en Visual J++ de
la Corporación Microsoft®, versión 6.0. Sin embargo, la presente
invención no está limitada de manera alguna al lenguaje J++, sino
que es extensamente aplicable a cualquier sistema de programación
orientado a objetos, tal como el C++, o a un sistema de programación
basado en objetos, tal como el Visual Basic de Microsoft®. Según se
utiliza aquí, el término "orientado a objetos" significa un
lenguaje de programación que está basado en objetos y que brinda a
la vez soporte a la herencia. El término "basado en objetos"
significa un lenguaje de programación en el cual el código fuente
se organiza en objetos, pero que no necesariamente brinda soporte a
la herencia, tal como el Visual Basic de Microsoft®.
Antes de describir la invención en detalle, se
presenta en la Figura 3 un ejemplo sencillo de un programa de
ordenador 30 en J++ que utiliza delegados, en el cual una instancia
del delegado encapsula un método sobre la instancia. En este caso,
se llama al método "hola" utilizando un delegado "f".
Además, la declaración del delegado define las clases de métodos
que el delegado es capaz de encapsular.
El ejemplo de programa de la Figura 3 ilustra
cómo se instancia una instancia f del delegado SimpleDelegate ("f
= new SimpleDelegate (o.hola)"), y cómo se invoca a
continuación ("f.invoke()"). Como se describe más en detalle
más adelante, a fin de ser válido y ejecutable, el tipo del
delegado SimpleDelegate debe coincidir con el tipo del método
"hola" referenciado. En este caso, ni "hola" ni
SimpleDelegate requieren ningún parámetro de entrada y ambos tienen
salida vacía. Como también se explica más adelante, este requisito
hace que los delegados tengan tipos protegidos.
Más adelante se expone una descripción de los
delegados, como una extensión del lenguaje J++, según se ha
implementado en la versión 6.0 del "Visual J++ de Microsoft®. La
Especificación del Lenguaje Java, según lo publicado por Sun
Microsystems, Inc". La Especificación del Lenguaje Java se
menciona aquí alternativamente como "ELJ" y, además, es citada
aquí parcialmente.
Una declaración de delegado, según el
ejemplo de realización de la invención expuesto aquí, especifica
una nueva clase que deriva de Delegate o de MulticastDelegate. La
DeclaracionDelegado tiene la forma:
- ModificadoresDelegado_{opt} delegate TipoResultado Identificador (ListaParámetrosFormales_{opt}) Throws_{opt}
Las producciones relevantes para la declaración
de clase son:
- ModificadoresClase_{opt} class Identificador Super_{opt} Interfaces_{opt} CuerpoClase
Una DeclaracionDelegado da como resultado
una clase que, si se declara utilizando la sintaxis del lenguaje
Java del ejemplo actual, tiene los siguientes atributos:
- 1)
- Para ModificadoresClase_{opt}, la declaración de clase tiene ModificadoresDelegado_{opt}, más los siguientes modificadores adicionales, suponiendo que puedan especificarse en el contexto dado: static, final.
- 2)
- Para Identificador, tiene el Identificador de la DeclaraciónDelegado.
- 3)
- Para Super_{opt}, tiene "extends com.ms.lang.MulticastDelegate" si se especifica el modificador multicast y "extends com.ms.lang.Delegate" si se omite el modificador multicast.
- 4)
- Para Interfaces_{opt}, tiene "".
Se infiere que si un delegado está declarado en
un paquete con nombre (véase \NAK 7.4.1 de la ELJ), con un nombre
P completamente calificado (véase \NAK 6.7 de la ELJ),
entonces el delegado tiene el nombre P.Identificador,
completamente calificado. Si el delegado está en un paquete
innominado (véase \NAK 7.4.2 de la ELJ), entonces el delegado
tiene el nombre Identificador, completamente calificado. En
el ejemplo de la Figura 4, el delegado EmptyMethod (32) se declara
en una unidad de compilación sin ninguna sentencia de paquete y,
por lo tanto, EmptyMethod es su nombre completamente calificado,
mientras que en el ejemplo de código fuente 34 de la Figura 5A el
nombre completamente calificado del delegado EmptyMethod es
vista.EmptyMethod.
En el presente ejemplo de realización de la
invención, el compilador 14 (ejecutable en una plataforma
informática digital) genera un error de tiempo de compilación:
- 1)
- si el Identificador que nombra a un delegado aparece como el nombre de cualquier otro tipo de delegado, tipo de clase o tipo de interfaz declarado en el mismo paquete (Véase \NAK 7.6 de la ELJ); o bien
- 2)
- si el Identificador que nombra a un delegado también es declarado como un tipo por una declaración de importación-de-tipo-individual (Véase \NAK 7.5.1 de la ELJ) en la unidad de compilación (Véase \NAK 7.3 de la ELJ) que contiene a la declaración del delegado.
El Identificador en una declaración de
delegado especifica el nombre del delegado. Este nombre de delegado
tiene como su ámbito (Véase \NAK 6.3 de la ELJ) todo el paquete
en el cual se declara el delegado.
Una declaración de delegado puede incluir
modificadores de delegado. Los ModificadoresDelegado
pueden estar ausentes o ser uno de los siguientes: public [público]
private [privado] static [estático] final multicast
[multiforme].
Si dos o más modificadores de delegado aparecen
en una declaración de delegado, es usual, entonces, aunque no
requerido, que aparezcan en un orden consistente con el mostrado
más atrás en la producción para ModificadoresDelegado.
Una declaración de delegado que incluye el
modificador multicast [multiforme] debe tener un
TipoResultado con valor void [vacío]; en caso contrario,
ocurre un error de compilación.
El modificador de acceso public [público] se
expone en \NAK 6.6 de la ELJ. El compilador de este ejemplo de
realización de la invención produce un error de tiempo de
compilación si:
- 1)
- se utiliza más de un modificador de delegado;
- 2)
- el mismo modificador aparece más de una vez en una declaración de delegado, o una declaración de delegado tiene más de un miembro del par de modificadores de acceso public [público] y private [privado]; o bien
- 3)
- el modificador private [privado] aparece en una declaración de delegado que no está anidada dentro de una clase.
Los delegados son implícitamente estáticos. Está
permitido, pero se desaconseja enfáticamente como cuestión de
estilo, especificar redundantemente el modificador static
[estático] dentro de una declaración de delegado. Además, los
Delegados son implícitamente final [finales]. Está permitido, pero
se desaconseja enfáticamente como cuestión de estilo, especificar
redundantemente el modificador final dentro de una declaración de
delegado.
Según el actual ejemplo de realización, las
definiciones de delegados pueden aparecer en todo sitio donde
aparecen definiciones de clase. Igual que una definición de clase,
una definición de delegado puede anidarse dentro de una definición
de clase. Además, los Delegados siempre son de nivel supremo.
Los miembros de un delegado incluyen a los
miembros heredados de la clase básica (ya sea clase Delegate o
MulticastDelegate), más un método de invocación especial, creado
automáticamente (descrito más adelante) que puede emplearse para
invocar el método encapsulado. Una declaración de delegado también
se obtiene como resultado en una clase con un constructor especial,
automáticamente generado.
Los miembros de un delegado incluyen un método de
invocación automáticamente creado, que puede emplearse para invocar
el método encapsulado. La signatura y el tipo devuelto por el
método Invoke están determinados por la declaración de delegado.
Específicamente, la signatura del método Invoke es:
TipoResultado
invoke (ListaParámetrosFormales_{opt})
Throws_{opt}
donde TipoResultado,
ListaParámetrosFormales (en caso de haberla) y Throws
(en caso de haberlo) son los de la declaración del
delegado.
Los delegados tienen dos constructores, según lo
siguiente:
- 1)
- Un constructor de "instancias" cuya forma está definida por la clase básica Delegate. Los argumentos para este constructor, un Objeto y un nombre de método en una Cadena de Caracteres, combinados con el tipo del delegado, especifican unívocamente un miembro del objeto indicado que coincide con la definición del delegado. El nuevo delegado construido encapsula este método.
- 2)
- Un constructor especial "designador de método" que permite que la mayor parte de la resolución del método se lleve a cabo en tiempo de compilación en lugar de durante la ejecución. El delegado designador de método no se expone a través del Reflejo del Núcleo de Java.
Los constructores de clase e instancia no son
especiales en manera alguna; se explican en detalle en la
especificación de la clase básica Delegate expuesta aquí. Se
utiliza una expresión designadora de método para indicar un método
de clase o instancia con el fin de la instanciación del
delegado.
La ExpresiónCreaciónInstanciaClase adopta
la forma
- new TipoClase (ListaArgumentos_{opt}) ExpresiónInstanciaciónDelegado
La ExpresiónInstanciaciónDelegado adopta
la forma:
- new TipoDelegado (DesignadorMétodo)
El DesignadorMétodo adopta la forma:
- NombreMétodo
- Primary.Identificador
- super.Identificador
El TipoDelegado es
- una clase que deriva de com.ms.lang.Delegate
Un designador de método no es suficiente para
designar un método. Para designar un método específico, en lugar de
(potencialmente) un conjunto de métodos, es necesario remitirse al
tipo devuelto y a la signatura (número y tipos de argumentos) del
delegado que se está instanciando con el designador de método. Por
este motivo, el DesignadorMétodo y la forma de especificación
de la nueva instancia se describen como una única unidad.
La instanciación de delegados emplea reglas de
búsqueda que son similares a las de las expresiones de invocación
de métodos (Véase \NAK 15.11 de la ELJ). La designación de un
método es compleja debido a la posibilidad de sobrecarga del método
y de prevalencia de métodos de la instancia. La determinación del
método que será invocado por una expresión de invocación de método
involucra varias etapas adicionales. Se describen a continuación
las etapas involucradas en la instanciación de delegados, tanto en
tiempo de compilación como en tiempo de ejecución, según el actual
ejemplo de realización de la(s) invención(es).
En el ejemplo de la Figura 3, la instanciación
"f = new SimpleDelegate(o.hola)" es un delegado
de enlace temprano, en el cual el método "hola" es conocido en
tiempo de compilación. En algunos casos, el método al cual debería
enlazarse el delegado no se conoce cuando se compila el programa.
Por ejemplo, el usuario de un entorno de desarrollo interactivo
podría especificar el nombre de un método para el prototipado de un
programa, o el nombre de un método a invocar podría calcularse o
ingresarse de alguna otra manera. En este caso, puede construirse
una instancia de un delegado utilizando un constructor de dos
argumentos.
El primer argumento del constructor especifica el
objeto sobre el que debería invocarse el método. El segundo
argumento del constructor especifica el nombre del método. El
objeto especificado en el primer argumento se verifica para
cerciorarse de que tiene un método del nombre indicado, con la misma
signatura (esto es, el tipo devuelto y los tipos de argumentos) con
la cual fue declarada la clase delegate. De no ser así, ocurre una
excepción; si lo es, se construye y devuelve un nuevo objeto
delegado.
La instanciación de tal delegado "de enlace
tardío", según lo descrito inmediatamente antes, adopta la
forma, por ejemplo, de "g = new
SimpleDelegate(o,"hola")", en la cual el método
"hola" es una cadena de caracteres que puede definirse durante
la ejecución del programa. En el caso del delegado de enlace
tardío, la invocación adopta la forma de
"g. dynamicInvoke (Objeto \talloblong
argumentos)". A manera de ilustración, el ejemplo de programa
36 de la Figura 5B construye un delegado de enlace tardío basado en
un nombre de método de tipo cadena de caracteres.
Como se ha observado anteriormente, el ejemplo de
realización de la presente invención incluye un compilador 14. Se
requieren varias etapas para procesar una expresión de
instanciación de delegado en tiempo de compilación. En primer
lugar, el compilador debe determinar qué clase o interfaz buscar. En
segundo lugar, el compilador debe buscar un método que sea
coincidente y accesible. En tercer lugar, el
compilador debe verificar que el método sea adecuado. Estos
procesos se describen en más detalle más adelante.
La primera etapa al procesar una expresión de
instanciación de delegado en tiempo de compilación es determinar el
nombre del método, y qué clase o interfaz verificar en cuanto a las
definiciones de métodos de ese nombre. Hay varios casos a
considerar, según la forma del designador de método, según lo
siguiente
- 1)
- Si la forma es NombreMétodo, entonces hay dos subcasos:
- a)
- Si es un nombre simple, es decir, sólo un Identificador, entonces el nombre del método es el Identificador, y la clase o interfaz a buscar es aquella cuya declaración contiene el designador del método.
- b)
- En todos los demás casos, el nombre calificado tiene la forma NombreCampo.Identificador; en tal caso, el nombre del método es el Identificador y la clase o interfaz a buscar es el tipo declarado del campo nombrado por el NombreCampo.
- 2)
- Si la forma es Primary.Identificador, entonces el nombre del método es el Identificador y la clase o interfaz a buscar es el tipo de la expresión Primary.
- 3)
- Si la forma es super.Identificador, entonces el nombre del método es el Identificador, y la clase a buscar es la superclase de la clase cuya declaración contiene la instanciación del delegado. Se produce un error de tiempo de compilación si tal designador de método aparece en una interfaz, o en la clase Object, o en un método estático, un inicializador estático, o el inicializador para una variable estática. Se infiere que un designador de método de esta forma puede aparecer sólo en una clase que no sea Object, y sólo en el cuerpo de un método de instancia, el cuerpo de un constructor, o un inicializador para una variable de instancia.
La segunda etapa busca la clase o interfaz
determinada en la etapa anterior para las declaraciones de método.
Esta etapa utiliza el nombre del método indicado y los tipos de los
parámetros formales de la definición del delegado para localizar
las declaraciones de métodos que sean tanto coincidentes como
accesibles, es decir, declaraciones que coincidan con el
tipo de los delegados que se están instanciando, y que puedan ser
correctamente invocadas desde el contexto de instanciación del
delegado. Debido a que las reglas de coincidencia son estrictas,
sólo puede haber una tal declaración de método.
Un método coincide con un tipo de
delegado, o no. Es posible instanciar una instancia de delegado del
tipo T, que encapsula el método M, si y sólo si
M coincide con T.
Sea M el método y sea T el tipo del
delegado. M coincide con T si y sólo si es verdad
todo lo que sigue:
- 1)
- M y T tienen el mismo número de parámetros formales;
- 2)
- El tipo de cada uno de los parámetros de M coincide idénticamente con el tipo de los parámetros de T;
- 3)
- El tipo del resultado de M coincide idénticamente con el tipo del resultado de T; y
- 4)
- En M no hay declaraciones para generar más excepciones verificadas que T. Si M tiene una cláusula "throws" que menciona cualquier tipo de excepción verificada, entonces T debe tener una cláusula "throws", y para cada tipo de excepción verificada enumerada en la cláusula "throws" de M, debe aparecer la misma clase de excepción o una de sus superclases en la cláusula "throws" de T.
Nótese que, debido a que las reglas de
coincidencia requieren una coincidencia estricta (tipos idénticos
para las listas de parámetros y los tipos devueltos), puede haber a
lo sumo un método coincidente para todo destino dado.
La clase o interfaz determinada por el proceso
aquí descrito es inspeccionada en busca de una declaración de
método que coincida con el tipo del delegado; las definiciones de
métodos heredadas de superclases y superinterfaces se incluyen en
esta búsqueda. El que una declaración de método sea accesible
o no para una invocación de método depende del modificador de
acceso (public [público], none [ninguno], protected [protegido] o
private [privado]) en la declaración del método y de dónde aparece
el designador del método. Si la clase o interfaz no tiene ninguna
declaración de método que sea a la vez coincidente y accesible,
entonces se genera un error de tiempo de compilación.
Si hay una declaración de método coincidente y
accesible para una expresión de instanciación de delegado, se la
llama la declaración de tiempo de compilación para la
expresión de instanciación del delegado. Deben realizarse varias
comprobaciones adicionales sobre la declaración de tiempo de
compilación. Se genera un error de tiempo de compilación si:
- 1)
- El designador de método tiene un NombreMétodo de la forma Identificador, y el designador de método aparece dentro de un método estático, un inicializador estático, o del inicializador para una variable estática;
- 2)
- El designador de método tiene un NombreMétodo de la forma NombreTipo.Identificador.
La siguiente información de tiempo de compilación
se asocia entonces con la invocación del método para su empleo en
tiempo de ejecución:
- 1)
- Una referencia a la declaración de tiempo de compilación. (El método).
- 2)
- La clase o interfaz que contiene la declaración de tiempo de compilación. (El destino).
- 3)
- La modalidad de invocación, calculada según lo siguiente:
- a)
- Si la declaración de tiempo de compilación tiene el modificador private [privado], entonces la modalidad de invocación es no virtual.
- b)
- En caso contrario, si la parte de la invocación del método antes del paréntesis izquierdo es de la forma super.Identificador, entonces la modalidad de invocación es super.
- c)
- En caso contrario, si la declaración de tiempo de compilación está en una interfaz, entonces la modalidad de invocación es de interfaz.
- d)
- En caso contrario, la modalidad de invocación es virtual.
La presente invención proporciona adicionalmente
el software intérprete 16 de Java VM (Figura 1) para implementar
los delegados de la presente invención. Se requieren varias etapas
para procesar una expresión de instanciación de delegado en tiempo
de ejecución. En primer lugar, el compilador debe verificar la
accesibilidad del tipo y método de destino. En segundo lugar, el
compilador debe localizar el método a invocar, teniendo en cuenta
la posibilidad de la prevalencia sobre métodos de instancias.
Sea C la clase que contiene la expresión de
instanciación del delegado, y sea T la clase o interfaz que
contenía la declaración de tiempo de compilación para la
expresión de instanciación del delegado, y sea m el nombre del
método, según lo determinado en tiempo de compilación.
El software intérprete 16 de Java VM comprueba,
como parte del enlace, que el método m aún existe en el tipo
T. Si esto no es verdad, entonces se produce una
IllegalArgumentException [excepción por argumento ilegal] (que es
una subclase de RuntimeException [Excepción de Tiempo de
Ejecución]). Si la modalidad de invocación es de interfaz, entonces
el software de la máquina virtual 16 debe también comprobar que el
tipo de referencia de destino aún implementa la interfaz
especificada. Si el tipo de referencia de destino no implementa aún
la interfaz, entonces se produce un IncompatibleClassChangeError
(Error de Cambio de Clase Incompatible).
El software de la máquina virtual 16 también debe
comprobar, durante el enlace, que el tipo T y el método
m son accesibles.
Para el tipo T:
- 1)
- Si T está en el mismo paquete que C, entonces T es accesible.
- 2)
- Si T está en un paquete distinto que C, y T es público, entonces T es accesible.
Para el método m:
- 1)
- Si m es público, entonces m es accesible. (Todos los miembros de interfaces son públicos (Véase \NAK 9.2 de la ELJ)).
- 2)
- Si m es protegido, entonces m es accesible si y sólo si T está en el mismo paquete que C, o bien C es T o una subclase de T.
- 3)
- Si m tiene acceso de paquete (valor por omisión), entonces m es accesible si y sólo si T está en el mismo paquete que C.
- 4)
- Si m es privado, entonces m es accesible si y sólo si C es T.
Si T o m no son accesibles,
entonces se produce una IllegalAccessException [Excepción por
Acceso Ilegal] (Véase \NAK 12.3 de la ELJ).
La estrategia para la búsqueda del método depende
de la modalidad de invocación. En el presente ejemplo de
realización, no es posible encapsular un método estático con un
delegado y, por lo tanto, es claro que un método de instancia ha de
ser encapsulado por el delegado, y hay una referencia de destino. Si
la referencia de destino es nula, se genera una
NullPointerException [Excepción por Puntero Nulo] en este punto. En
caso contrario, se dice que la referencia de destino se refiere a
un objeto de destino y se utilizará como el valor de la
palabra clave "this" cuando se invoque al delegado. Las otras
cuatro posibilidades para la modalidad de invocación son
consideradas luego por el software intérprete 16 de Java VM, según
lo siguiente.
Si la modalidad de invocación es no virtual, no
se permite la prevalencia. El método m de la clase T
es el que se invoca. En caso contrario, la modalidad de invocación
es de interfaz, virtual o super, y puede tener lugar la
prevalencia. Se utiliza una búsqueda dinámica de método. El
proceso de búsqueda dinámica comienza a partir de una clase
S, determinada según lo siguiente:
- 1)
- Si la modalidad de invocación es de interfaz o virtual, entonces S es inicialmente la clase efectiva R de tiempo de ejecución del objeto de destino. Si el objeto de destino es una formación, R es la clase Object. (Nótese que para la modalidad de invocación de tipo interfaz, R implementa a T necesariamente; para la modalidad de invocación virtual, R es necesariamente T o bien una subclase de T).
- 2)
- Si la modalidad de invocación es super, entonces S es inicialmente la superclase de la clase C que contiene la instanciación del delegado.
La búsqueda dinámica de método emplea el
siguiente procedimiento para buscar en la clase S, y luego
en las superclases de la clase S, de ser necesario, el
método m:
- 1)
- Si la clase S contiene una declaración de un método llamado m con el mismo descriptor (el mismo número de parámetros, los mismos tipos de parámetros y el mismo tipo de devolución) requerido por la invocación del método, según lo determinado en tiempo de compilación (descrito precedentemente), entonces este es el método que ha de ser encapsulado por el delegado, y el procedimiento termina.
- 2)
- En caso contrario, si S no es T, se realiza este mismo procedimiento de búsqueda utilizando la superclase de S; aquello que produzca es el resultado de esta búsqueda.
Este procedimiento encontrará un método adecuado
cuando llegue a la clase T, porque, en caso contrario, una
IllegalAccessException [Excepción por Acceso Ilegal] habría sido
generada por las comprobaciones descritas anteriormente. Se observa
que el proceso dinámico de búsqueda, si bien se describe aquí
explícitamente, a menudo se implementará implícitamente.
En el ejemplo de realización de delegados
expuesto aquí, hay procedimientos provistos para asegurarse de que
los delegados no se utilizan a fin de subvertir el código fuente
fiable. Sin precauciones especiales de seguridad, los métodos no
fiables pueden, potencialmente, utilizar delegados a fin de hacer
invocar métodos fiables, de tal manera que ninguna clase no fiable
aparezca en la pila de llamadas. Bajo la seguridad estándar de
Java, el método fiable tendría éxito si no hubiera métodos no
fiables en la pila de llamadas; fracasaría potencialmente si el
método no fiable original estuviera en la pila de llamadas. Un buen
ejemplo es el método java.io.File.delete; si un código fuente no
fiable llamara a este método se generaría una SecurityException
[Excepción de Seguridad]. Sin embargo, si un código no fiable
encapsulara este método fiable en un delegado y se lo pasara a un
código totalmente fiable que invocase entonces al delegado, el
método (java.io.File.delegate) tendría éxito. Por lo tanto, el
ejemplo de realización expuesto aquí realiza una comprobación
especial de seguridad al instanciar delegados, según se expone más
adelante. Esta comprobación de seguridad se realiza en tiempo de
ejecución.
El ejemplo de realización de la invención
expuesto aquí extiende el modelo estándar de seguridad de Java a
fin de asociar un conjunto de permisos de seguridad a cada clase de
Java. Para una clase dada, el conjunto asociado de permisos de
seguridad determina las operaciones fiables (tales como la Entrada /
Salida de ficheros y la impresión) que los métodos de la clase
están autorizados para realizar. Las clases no fiables tienen un
conjunto de permisos vacío, mientras que las clases totalmente
fiables tienen un conjunto de permisos completo (es decir, tienen
todos los permisos).
Para que una instanciación de delegado tenga
éxito en tiempo de ejecución, los permisos de C (la clase
que contiene la expresión de instanciación del delegado) debe ser
un superconjunto de los permisos poseídos por la clase que contiene
el método m, según lo determinado en tiempo de ejecución. Si
no es este el caso, se genera una IllegalAccessException [Excepción
por Acceso Ilegal]. Además, esta comprobación de seguridad requiere
que las clases derivadas de un delegado o de una clase
multidelegada sean de categoría final, permitiendo que una búsqueda
por la cadena de llamadas vea qué entidad está creando el delegado.
Una consecuencia directa es que las clases no fiables sólo puedan
crear delegados sobre métodos no fiables, mientras que las clases
totalmente fiables (es decir, las clases del sistema) pueden crear
delegados sobre todos los métodos accesibles.
Según lo descrito anteriormente, el compilador 14
y el software intérprete 16 son componentes de software distintos.
Sin embargo, estos componentes pueden, en algunos casos, realizar
las mismas funciones, tales como enlazar delegados, según la
modalidad de operación. Además, las funciones del compilador 14 y
del software intérprete 16 pueden, en algunos casos, intercambiarse
o compartirse entre sí. Por consiguiente, la invención no está
limitada en modo alguno por la división particular de funciones
expuesta en el ejemplo de realización descrito aquí. En cambio, el
compilador 14 y el software intérprete 16 deberían concebirse
compartiendo la tarea común de procesar código de ordenador basado
en objetos, a fin de prepararlo para su ejecución en un
ordenador.
Según lo observado anteriormente, todos los
delegados derivan de esta clase Delegate básica. Un objeto de tipo
Delegado encapsula una entidad invocable: una instancia y un método
de la instancia. Un ejemplo de definición 38 de la clase Delegate
se muestra en la figura 6.
El constructor protected Delegate
(Object destino, String NombreMetodo) inicializa un objeto
Delegate recién creado, de manera tal que encapsule el destino y el
método especificado por los argumentos. Si el destino es
nulo, entonces se activa una NullPointerException [Excepción por
Puntero Nulo]. El argumento NombreMetodo debe denotar un
método que sea coincidente, accesible y adecuado, según lo definido
precedentemente. Si no puede hallarse ningún método de destino
coincidente, se genera una IllegalArgumentException [Excepción por
Argumento Ilegal] en tiempo de ejecución. Si no se halla un método,
se genera un NoSuchMethodError [Error de No Hay Tal Método].
El resultado de public final boolean
equals (Object obj) es verdadero si y sólo si el
argumento no es nulo, y es un objeto Delegate que tiene el mismo
método de destino, y una lista de invocación como este objeto
Delegate. Observe que dos delegados no necesitan ser del mismo tipo
a fin de igualarse entre sí, según lo definido por Delegate.equals.
Esta expresión prevalece sobre el método equals del Objeto (Véase
\NAK 20.1.3 de la ELJ).
La expresión public static final Delegate
combine (Delegate a, Delegate b) combina los dos
delegados dados para formar un único delegado. Si tanto a como b
son nulos, el resultado es nulo. Si sólo a o b es nulo, el resultado
es el delegado no nulo. Si ni a ni b son nulos, el resultado es un
nuevo delegado con una lista de invocación formada por la
concatenación de las listas de invocación de a y b, en ese orden.
No se considera un error que la lista de invocación contenga
entradas duplicadas - entradas que se refieren al mismo método sobre
el mismo objeto. Si ni a ni b son nulos, entonces los delegados a y
b deben ser del mismo tipo efectivo. En caso contrario, una
IllegalArgumentException [Excepción por Argumento Ilegal] es
generada por el compilador 14. Si ni a ni b son nulos, entonces los
delegados a y b deben ser de un tipo efectivo que derive de la
clase DelegateMulticast. En caso contrario, una
MulticastNotSupportedException [Excepción por Multiformes no
Soportados] es generada por el compilador
14.
14.
La expresión public static final Delegate
combine (Delegate \talloblong delegados) envuelve un
delegado con una lista de invocación que consiste en la
concatenación de las listas de invocación de cada uno de los
delegados en la formación de delegados, en su orden. Si la lista de
invocación resultante es vacía, el resultado es nulo. La formación
de delegados puede contener entradas nulas; tales entradas son
ignoradas. Si el parámetro de la formación de delegados es nulo o
vacío, el resultado es nulo. Los elementos no nulos de la formación
de delegados deben ser del mismo tipo efectivo; en caso contrario,
se genera una IllegalArgumentException [Excepción por Argumento
Ilegal]. Si hay múltiples elementos no nulos en la formación de
delegados, entonces estos elementos deben ser de un tipo efectivo
que derive de la clase MulticastDelegate. En caso contrario, una
MulticastNotSupportedException [Excepción por Multiformes no
Soportados] es generada por el compilador 14.
La expresión public static final Delegate
remove (Delegate origen, Delegate valor) devuelve un
delegado con una lista de invocación formada al quitar la última
aparición (en caso de haberla) del delegado dado por el parámetro
valor de la lista de invocación del delegado dado por el
parámetro origen. El delegado quitado de la lista de
invocación es el último delegado para el cual es verdadera la
siguiente expresión: valor.equals (delegado), donde delegado
es el miembro en cuestión de la lista de invocación. Si el
parámetro valor es nulo, o si el delegado dado por el
parámetro valor no aparece en la lista de invocación del
origen, el resultado es el parámetro origen. Si la lista de
invocación resultante es vacía, el resultado es nulo. Si el
parámetro origen es nulo, el resultado es nulo.
La expresión public final Object
dynamicinvoke (Object \talloblong args) puede
utilizarse para invocar el método en modalidad de enlace tardío
(Delegate.dynamicInvoke). Cuando es llamado, el miembro
dynamicInvoke causa la ejecución del método que el delegado
encapsula, pasando los elementos del argumento args como argumentos
para el método. El resultado de dynamicInvoke es el resultado de la
invocación del método encapsulado. Si el resultado de la invocación
del método es una referencia a objeto, entonces se devuelve esta
referencia, En caso contrario, si el resultado es un valor
primitivo, entonces el valor primitivo se envuelve en un Objeto y
se devuelve. (P. ej., un valor booleano se envuelve en un objeto
Booleano). En caso contrario, el tipo de devolución del método es
vacío, y se devuelve un Objeto que contiene el valor nulo.
El método public final static Method
getMethod() devuelve una referencia al único objeto
Method que es el método del par (destino, método).
El método public final static Object
getTarget() devuelve una referencia a la parte de
instancia del dúo (instancia, método) que se necesita para
encapsular una entidad invocable.
El método public Delegate \talloblong
getInvocationList () devuelve la lista de invocación de
este delegado, en el orden de invocación. Para delegados no
multiformes, el resultado es siempre una formación con un único
elemento. Para delegados multiformes, descritos más adelante, la
formación resultante puede tener más de un elemento. Se garantiza
que la lista de invocación de cada uno de los elementos en la
formación devuelta tiene exactamente una entrada.
Todos los delegados multiformes derivan de la
clase MulticastDelegate, mencionada en este ejemplo de realización
de Java como la Clase com.ms.lang.MulticastDelegate. El efecto de
invocar un delegado multiforme puede ser que se invoquen múltiples
métodos. El conjunto de métodos invocados por el método de
invocación de un delegado se denomina la lista de invocación del
delegado, y puede obtenerse utilizando el método getInvocationList
[obtenerListaInvocación].
Un delegado que hereda directamente de Delegate
siempre tendrá una lista de invocación con un elemento - él mismo.
Un delegado que hereda de la clase MulticastDelegate puede tener
una lista de invocación con más de un elemento. Los métodos
Delegate.combine y Delegate.remove se utilizan para crear nuevas
listas de invocación.
Los métodos Invoke y dynamicInvoke multiplican su
acción invocando a cada uno de los delegados en la lista de
invocación con los argumentos transferidos. Los delegados se
invocan sincrónicamente, en el orden en que aparecen en la lista de
invocación. Si uno de los delegados devuelve una excepción, entonces
cesa la invocación múltiple, y se propaga la excepción hasta el que
ha llamado al método Invoke. Mientras transcurre un Invoke de
acción múltiple, pueden ocurrir llamadas a Delegate.combine y
Delegate.remove. Tales llamadas no afectan a la lista de invocación
empleada por la invocación múltiple que ya está transcurriendo.
En el presente ejemplo de realización de la
invención, la clase MulticastDelegate (40) se define como lo
ilustra la Figura 7.
La expresión protected
MulticastDelegate next es una referencia interna al
próximo delegado en la cadena de invocación múltiple. A fin de que
se preserve el orden correcto de invocación, debe invocarse el
delegado "next" antes de invocar el método que este delegado
encapsula.
El constructor protected
MulticastDelegate (Object destino, String NombreMetodo)
funciona como el constructor correspondiente definido en la clase
Delegate básica.
Una realización alternativa de invocar un
delegado multiforme es construir una formación de delegados a
invocar, recorriendo la cadena "next" del delegado multiforme.
Esta lista puede situarse en la pila del programa. El software
intérprete 16 de la máquina virtual recorre entonces esta formación
en orden inverso y llama al método de invocación de cada delegado,
con los parámetros que se han pasado al método de invocación del
delegado multiforme. La ventaja de esta técnica es que la pila del
programa no necesita ser tan profunda, dado que a lo sumo sólo dos
copias de los parámetros pasados al método de invocación del
delegado multiforme están en la pila.
Ejemplo alternativo de
realización
En un ejemplo alternativo de realización de la
invención, el lenguaje J++ se extiende adicionalmente para envolver
miembros estáticos en una clase. Con este fin, se proporciona un
constructor "class" cuya forma está definida por la clase
Delegate básica. Los argumentos para este constructor, una Clase y
un nombre de método de tipo String [Cadena de caracteres],
combinados con el tipo del delegado, especifican unívocamente un
miembro estático de la clase indicada que coincide con la
definición del delegado. El delegado recién construido encapsula
este método estático. Este constructor adopta la forma:
- protected Delegate (Class clase, String NombreMétodo)
- Este constructor inicializa un objeto Delegate recién creado de manera tal que encapsule el método estático especificado por los argumentos. Si la clase es nula, entonces se activa una NullPointerException [Excepción por Puntero Nulo]. El argumento NombreMétodo debe denotar un método que sea coincidente, accesible y adecuado, según lo definido anteriormente. Si no puede hallarse ningún método de destino coincidente, se genera una IllegalArgumentException [Excepción por Argumento Ilegal] en tiempo de ejecución. Si no se halla tal método, se genera una IllegalArgumentException.
En la primera etapa en tiempo de compilación para
los delegados que envuelven a miembros estáticos, debe determinarse
la clase o interfaz a buscar. Si es un nombre calificado de la
forma NombreTipo.Identificador, entonces el nombre del
método es el Identificador y la clase a buscar es la nombrada
por el NombreTipo. Si NombreTipo es el nombre de una
interfaz, en lugar de una clase, entonces ocurre un error de tiempo
de compilación, porque esta forma sólo puede designar a métodos
estáticos, y las interfaces no tienen métodos estáticos. También es
necesario determinar, como en el caso de la envoltura de miembros
de instancias de una clase, si el método es adecuado. Si hay una
declaración de método coincidente y accesible para una expresión de
instanciación del delegado, se la llama declaración de tiempo de
compilación para la expresión de instanciación del
delegado.
También deben realizarse otras comprobaciones
sobre la declaración de tiempo de compilación. Si el designador de
método tiene un NombreMétodo de la forma
Identificador, y el designador de método aparece dentro de un
método estático, o un inicializador estático, o en el inicializador
para una variable estática, entonces tiene lugar un error de tiempo
de compilación. En otros aspectos, la envoltura de miembros
estáticos es una extensión o modificación de la envoltura de
miembros de instancias, según lo descrito anteriormente.
Según esta realización alternativa, también se
proporciona un constructor correspondiente para la clase
MulticastDelegate: protected MulticastDelegate (Class
clase, String NombreMétodo). Este constructor funciona como el
constructor correspondiente definido en la clase Delegate
básica.
El Visual J++ de Microsoft® no brinda soporte a
la herencia múltiple. Sin embargo, a veces será necesaria tal
interfaz para convertir código fuente existente en un estilo de
tipo delegado. Esta situación puede extenderse análogamente a
java.lang.Thread frente a java.lang.Runnable. Para abordar este
problema, un ejemplo de realización de la invención extiende el
Visual J++ de Microsoft® para incluir una interfaz
com.ms.lang.Callable 42, según se muestra en la Figura 8.
Preferiblemente, los delegados implementan esta interfaz.
En la programación orientada a objetos, un suceso
es una construcción que permite que una fuente de sucesos notifique
anónimamente a un perceptor de sucesos (o conjunto de perceptores
de sucesos) que ha ocurrido una transición de estado de cierta
clase. Los sucesos se emplean, típicamente, en un sistema más
grande llamado un "modelo de componentes", que describe cómo un
componente expone su código de funcionalidad, que está utilizando
el componente. En un nivel fundamental, la mayoría de los modelos
modernos de componentes describen cómo un componente expone sus
propiedades (que describen el estado del componente), métodos (que
exponen acciones que el componente es capaz de realizar) y sucesos
(notificaciones del componente de que algo interesante ha
ocurrido).
Una invocación de suceso es como una llamada de
método a la inversa. Para una llamada de método, un consumidor de
componentes llama a un método del componente, pasándole un cierto
número de argumentos. Para un suceso, la llamada es en la dirección
opuesta - el componente llama a un método proporcionado por el
consumidor de componentes, pasándole un cierto número de argumentos.
Además de la diferencia en la dirección de la llamada, hay varias
otras diferencias notables.
Para una llamada de método, el consumidor,
típicamente, tiene una dependencia explícita del componente que
está siendo llamado. En cambio, las invocaciones de sucesos son
típicamente anónimas - el componente no tiene una dependencia
explícita del consumidor de componentes. En lugar de ello, los
perceptores pueden conectarse con un suceso o conjunto de sucesos
utilizando un mecanismo proporcionado por la fuente de los
sucesos.
Para una llamada de método, además, el llamado
determina la forma del método - el número y tipos de argumentos, y
el tipo de retorno. Para una indicación de suceso, el origen del
suceso (el llamador) determina la forma.
En el ejemplo de realización del modelo de
componentes basado en delegados según la presente invención,
descrito más adelante, los sucesos se utilizan, típicamente, para
la comunicación entre un componente (a menudo escrito por un
proveedor comercial) y el código de gestión de sucesos (escrito por
un desarrollador que utiliza el componente). El ejemplo de
realización del modelo de componentes descrito más adelante brinda
soporte tanto a los sucesos uniformes como a los multiformes.
Se describe más adelante cómo exponer y explotar
sucesos según este ejemplo de realización de la invención. Se
definen y exponen aquí varias clases:
- 1)
- La clase Event (Suceso). Los sucesos envuelven un estado interesante en un objeto de tipo suceso. Todos los tales objetos de tipo suceso derivan de la clase Event. La clase Event también se utiliza directamente para sucesos sin parámetros.
- 2)
- El delegado EventHandler [Gestor de Sucesos], que se utiliza en conjunción con la clase Event.
- 3)
- La clase CancelEvent [CancelarSuceso], que se utiliza para acciones que pueden cancelarse. Antes de que ocurra la acción, la fuente de sucesos notifica a los perceptores interesados que la acción está por ocurrir. Cada perceptor tiene la oportunidad de "cancelar" la acción.
- 4)
- El delegado CancelEventHandler [GestorCancelarSucesos], que se utiliza en conjunción con la clase CancelEvent [CancelarSuceso].
Para activar sucesos, una fuente de sucesos
realiza una o más de las siguientes acciones:
- 1)
- define una clase de sucesos;
- 2)
- define un delegado "gestor de sucesos";
- 3)
- proporciona métodos para "añadir" y "quitar", a fin de permitir que una fuente de sucesos se conecte con un suceso y posteriormente se desconecte de él; o bien
- 4)
- proporciona un método para "activar sucesos" que activa un suceso.
Esta es una clase que deriva de la clase Event
[Suceso] y, potencialmente, añade información contextual adicional.
A menudo no es necesario definir una nueva clase de suceso, porque
puede emplearse una clase de sucesos existente.
Las clases de sucesos se utilizan por convención.
Es posible definir y utilizar sucesos que no emplean clases de
sucesos en absoluto. El presente ejemplo de modelo de componentes
recomienda empaquetar sucesos como objetos, a fin de facilitar los
escenarios de despacho de sucesos y la generación de versiones.
Estos temas se exponen adicionalmente aquí más adelante. Para los
sucesos de ratón activados por una clase de ventanas, podría
definirse la clase de sucesos mostrada en la Figura 9.
Un tal delegado se necesita para cada conjunto
interesante de sucesos. Tal delegado puede ser utilizado por
múltiples sucesos. Por convención, se definen delegados gestores de
sucesos que coincidan con el patrón:
- public multicast delegate void <Nombre>Handler (Object origen, <TipoSuceso> e);
Para el ejemplo del suceso de ratón 44 de la
Figura 9, esto implica:
- public multicast delegate void MouseEventHandler (Object origen, MouseEvent e);
El ejemplo de realización del modelo de gestión
de sucesos expuesto aquí proporciona métodos para "añadir" y
"quitar", que permiten que una fuente de sucesos se conecte
con el suceso, y posteriormente se desconecte de él. Por
convención, se definen delegados gestores de sucesos que coincidan
con el patrón:
- public void addOn<NombreSuceso>Handler (<TipoGestorSucesos> gestor);
- public void removeOn<NombreSuceso>Handler (<TipoGestorSucesos> gestor);
Para el ejemplo de sucesos de ratón, esto
implica:
- public void addOnMouseMoveHandler(MouseEventHandler gestor);
- public void removeOnMouseMoveHandler(MouseEventHandler gestor);
Este método permite que las clases derivadas
activen el suceso, cancelen el suceso que ha sido activado en una
clase básica, y proporcionen el procesamiento previo y
procesamiento posterior sin interferencia de los consumidores de
componentes. El cuerpo del método activa el suceso llamando al
Delegate.invoke para la propiedad adecuada, con valor de delegado,
pasando los argumentos y añadiendo "this" como el valor del
parámetro de origen para el suceso. Para las clases de categoría
final, no hay necesidad de proporcionar tal método, ya que no es
posible que existan clases derivadas. Por convención, se definen
delegados gestores de sucesos que coincidan con el patrón:
- protected void on<NombreSuceso> (<TipoSuceso> e);
Para el ejemplo de suceso de ratón, se hace
referencia al método 46 ilustrado en la Figura 10.
Para percibir sucesos, un perceptor de sucesos
hace lo siguiente:
- 1)
- Aprende qué sucesos están disponibles para un componente, utilizando la clase ComponentManager [AdministradorComponentes], que se describe en la ELJ.
- 2)
- Crea una función gestora de sucesos con la signatura correcta, según lo definido por el delegado utilizado para la correspondiente propiedad de suceso, por ejemplo, según se muestra en el código fuente 48 de la Figura 11.
- 3)
- Conecta el código de gestión de sucesos con el suceso, llamando al método "add" ["añadir"] proporcionado por la fuente de sucesos, por ejemplo, según se muestra en el código fuente 50 de la Figura 12.
- 4)
- Optativamente, desconecta el código gestor de sucesos del suceso, llamando al método "remove" ("quitar") proporcionado por la fuente; por ejemplo, según se muestra en el código fuente 52 de la Figura 13. En la mayoría de los casos, no hay necesidad de desconectarse explícitamente.
Las Figuras 14A-14B ilustran el
ejemplo de código J++ 54, que muestra la aplicación del modelo de
delegados y sucesos descrito anteriormente. En las Figuras
14A-14B, se declara una clase de sucesos de ratón y
un delegado gestor de sucesos de ratón. También se expone una
declaración de clase box (cuadro), así como una ilustración de un
consumidor de componentes que utiliza dos instancias de cuadro.
Un ejemplo sencillo de suceso en el cual se
activa un suceso sin ningún parámetro, según se ilustra en las
Figuras 15A-15B. En el programa de J++ 56 de las
Figuras 15A-15B, el control Smiley [Emoticón] activa
un suceso cuando su propiedad "feliz" cambia.
El modelo de sucesos descrito anteriormente
funciona igualmente bien para escenarios uniformes y multiformes.
Por convención preferida en el ejemplo de realización expuesto
aquí, todos los sucesos son multiformes. La definición de un suceso
uniforme es bastante fácil de realizar, sin embargo - sólo omitir el
modificador Multicast [multiforme] en la declaración del delegado.
Los sucesos pueden aparecer tanto en las definiciones de clase como
en las interfaces. Es posible definir un conjunto de sucesos en una
interfaz, y hacer que múltiples clases brinden soporte a esta
interfaz.
La diferencia principal entre un modelo de
sucesos multiforme y un modelo de sucesos uniformes está en cómo se
realiza la conexión. Con los multiformes, es necesario utilizar un
delegado multiforme y emplear los métodos "addOn"
["añadirCuando"] y "removeOn" ["quitarCuando"]. Para
los uniformes, es posible emplear un delegado no multiforme y
permitir que la conexión / desconexión con un suceso se realice con
asignaciones (set) y obtenciones (get) de propiedades. Es decir, un
componente proporciona una propiedad con valor de delegado para
cada uno de los sucesos que expone. Por ejemplo, para un suceso
MouseMove (MoverRatón) un componente, para exponer un suceso
"pepe", expondría una propiedad "OnPepe", como se ilustra
en el código fuente 58 mostrado en la figura
16.
16.
La clase Event (Suceso) cumple diversos
fines:
1) Actúa como la clase básica para todos los
sucesos. Por convención, los sucesos para los componentes emplean
un único parámetro, cuyo tipo es una clase que deriva de la clase
Event.
2) Se utiliza para sucesos que no tienen ningún
estado. El miembro estático EMPTY se utiliza usualmente con este
fin, y permite que un suceso se active eficientemente, según lo
ejemplificado en el código fuente 60 ilustrado en la Figura 17.
El delegado EventHandler se utiliza para sucesos
que toman un único parámetro de tipo Event, según se ilustra en el
código fuente 62 de la Figura 18.
La clase CancelEvent se utiliza para sucesos que
se refieren a una acción que puede cancelarse. La clase CancelEvent
proporciona un campo booleano, llamado "cancel", que dice si
la acción en cuestión ha sido cancelada. Un valor de verdad indica
que la acción ha sido cancelada; un valor de falsedad indica que la
acción no ha sido cancelada. Puede proporcionarse un valor inicial
para "cancel", utilizando el constructor proporcionado.
Típicamente, "cancel" se inicializa con el valor de falsedad,
de manera tal que si el suceso no es gestionado, o si el gestor de
sucesos no altera el campo "cancel", la fuente del suceso
supone que el permiso para realizar la acción ha sido concedido. La
clase CancelEvent se ilustra en el código fuente 64 de la Figura
19.
El delegado CancelEventHandler se utiliza para
sucesos que toman un único parámetro del tipo CancelEvent, según se
ilustra en el código 66 de la Figura 20.
Como se ha demostrado anteriormente, los
delegados son útiles en general, en particular, para entornos
relacionados con sucesos. Sin embargo, también son útiles para
entornos no orientados a sucesos, tales como un sustituto para el
mecanismo de retrollamada en J/Direct y para la invocación
débil.
El ejemplo de realización de los modelos de
delegados y sucesos de la presente invención, descrito aquí, se
expresa como una extensión del Visual J++ de Microsoft®. Sin
embargo, se entenderá que las invenciones expuestas aquí son
ampliamente aplicables a otros sistemas de lenguajes de programación
orientada a objetos, tales como C++, y a lenguajes de programación
basados en objetos, tales como Visual Basic de Microsoft®, o a
otras versiones de J++ disponibles en la Corporación Microsoft o en
otros desarrolladores.
Además, las invenciones expuestas aquí son
aplicables a, y toman la forma de, tanto programas de ordenador
escritos utilizando el código fuente de la presente invención, como
compiladores y máquinas virtuales de tiempo de ejecución, y otros
sistemas de programación que traducen programas de ordenador en
comandos ejecutables por un sistema informático.
La invención proporciona además la realización de
modelos de delegados y sucesos en forma de código de un ordenador
físico, o de un portador, tal como, pero no limitado a, un
controlador de disco rígido, un disquete, memoria de ordenador o
señales electrónicas que puedan utilizarse para transportar tal
código desde un ordenador o medio de almacenamiento a otro.
Además, aunque las realizaciones reveladas aquí
se implementan en software, las invenciones expuestas aquí no están
en modo alguno limitadas exclusivamente a la implementación en
software, y contemplan expresamente la implementación en firmware y
en lógica cableada basada en silicón, o de otras formas, o
combinaciones de lógica cableada, firmware y software, o
cualesquiera sustitutos adecuados de los mismos.
De esta manera, se ha descrito en lo anterior un
método y dispositivo para encapsular una referencia a un método en
sistemas de programación orientados a objetos o basados en objetos,
y para garantizar que la referencia es segura. Como se ha expuesto
en lo anterior, la invención provee:
- a)
- definir una entidad que define la forma del método al cual referirse;
- b)
- obtener una referencia a un método;
- c)
- almacenar esta referencia en estructuras de datos arbitrarias;
- d)
- pasar la referencia a código escrito por terceros;
- e)
- permitir la invocación del método por parte de cualquiera que tenga la referencia al método; y
- f)
- permitir al tenedor de una referencia a un método determinar el objeto y método de destino a los cuales se hace referencia.
Además, el sistema de programación de la presente
invención logra los objetivos precedentes de una manera
caracterizada por tipos fuertes, haciendo posible que:
- a)
- los desarrolladores conozcan pronto los problemas de la falta de coincidencia de tipos (en tiempo de compilación) y no tarde (en tiempo de ejecución); y
- b)
- las herramientas de desarrollo presenten información a los desarrolladores acerca de la forma de los componentes que utilizan delegados.
Además, la invención provee programación basada
en sucesos, en donde el código relacionado con sucesos puede
encapsularse en delegados.
Claims (19)
1. Un producto de programa de ordenador basado en
objetos, que comprende un código de programa de ordenador,
realizado en una forma legible por ordenador, sobre un portador
físico (22; 24; 26; 28), en el cual el código fuente del programa
causa que un ordenador (20) lleve a cabo las etapas de representar
una instancia y un primer método de una clase por medio de un valor
delegado, que puede asignarse a variables y transferirse desde un
procedimiento a otro, y de invocar al primer método llamando a un
segundo método de una instancia de una clase, utilizando el valor
delegado, en el cual los parámetros proporcionados al segundo
método se proporcionan al primer método, y la lista de parámetros
del segundo método coincide con la lista de parámetros del primer
método; y en el cual, además, el primer método es identificado por
nombre y por la coincidencia de la lista de parámetros y del tipo
del resultado del primer método con la lista de parámetros y el
tipo de resultado declarado para la clase.
2. Un producto de programa de ordenador según la
reivindicación 1, en el cual, además, la instancia de la clase está
representada por un valor que puede asignarse a variables y pasarse
desde un procedimiento a otro.
3. Un producto de programa de ordenador según la
reivindicación 2, en el cual, además, el código del programa causa
que el ordenador (20) invoque al segundo método sobre una variable
a la que ha sido asignado un valor que representa una instancia de
la clase.
4. Un producto de programa de ordenador según la
reivindicación 1, en el cual, además, los sucesos se gestionan
utilizando el primer método.
5. Un producto de programa de ordenador según la
reivindicación 1, en el cual, además, el ordenador (20) invoca uno
o más primeros métodos adicionales con la llamada al segundo
método, y en el cual se proporciona al segundo método uno o más
conjuntos de parámetros correspondientes adicionales, para que sean
proporcionados respectivamente al primer método, o a los primeros
métodos adicionales.
6. Un producto de programa de ordenador según la
reivindicación 5, en el cual, además, hay creada una lista de
invocación asociada con el segundo método, en el cual la lista de
invocación especifica el primer método a invocar.
7. Un producto de programa de ordenador según la
reivindicación 6, en el cual, además, se añaden y se borran los
primeros métodos de la lista de invocación.
8. Un sistema de programación basado en objetos
que comprende un ordenador (20) adaptado para representar una
instancia y un primer método de una clase por un valor de delegado,
que puede asignarse a variables y pasarse desde un procedimiento a
otro; y para invocar un primer método, con una llamada a un segundo
método de una instancia de una clase utilizando el valor de
delegado, en el cual los parámetros proporcionados al segundo
método son proporcionados al primer método, y la lista de
parámetros del segundo método coincide con la lista de parámetros
del primer método, y en el cual, además, el primer método se
identifica por nombre y por la coincidencia de la lista de
parámetros y del tipo de resultado del primer método con la lista
de parámetros y el tipo de resultado declarado para la clase.
9. Un sistema de programación según la
reivindicación 8, en el cual, además, la instancia de la clase está
representada por un valor que puede asignarse a variables y pasarse
desde un procedimiento a otro.
10. Un sistema de programación según la
reivindicación 9, en el cual, además, el código del programa causa
que el ordenador (20) invoque al segundo método sobre una variable
a la que se ha asignado un valor que representa una instancia de la
clase.
11. Un sistema de programación según la
reivindicación 8, en el cual, además, los sucesos se gestionan
utilizando el primer método.
12. Un sistema de programación según la
reivindicación 8, en el cual, además, el ordenador invoca a uno o
más primeros métodos adicionales con la llamada al segundo método,
en donde uno o más conjuntos de parámetros adicionales
correspondientes se proporcionan al segundo método, para ser
respectivamente proporcionados al primer método, o a los primeros
métodos adicionales.
13. Un sistema de programación según la
reivindicación 12, en el cual, además, hay creada una lista de
invocación, asociada con el segundo método, en donde la lista de
invocación especifica los primeros métodos a invocar.
14. Un sistema de programación según la
reivindicación 13, en el cual, además, los primeros métodos se
añaden y se borran de la lista de invocación.
15. Un sistema de programación según la
reivindicación 8, en el cual, además, el ordenador está adaptado
con software.
16. Un sistema de programación según la
reivindicación 8, en el cual, además, el ordenador está adaptado
con hardware y software.
17. Un sistema de programación según la
reivindicación 8, en el cual, además, el sistema de programación
incluye un compilador (14).
18. Un sistema de programación según la
reivindicación 8, en el cual, además, el sistema de programación
incluye un intérprete (16).
19. Un método para programar un ordenador (20) en
código de ordenador basado en objetos, que comprende el empleo de
un ordenador (20) para realizar las etapas de programación de:
- a)
- definir una primera clase que tiene un primer método para ser utilizado a fin de hacer referencia a un segundo método de una segunda clase;
- b)
- representar una instancia de la primera clase con un valor de delegado, en donde una instancia de la segunda clase y el segundo método están identificados como parámetros de la instancia de la primera clase; e
- c)
- invocar el segundo método llamando al primer método sobre la instancia de la primera clase, empleando el valor para hacer referencia a la instancia.
Applications Claiming Priority (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| US09/089,619 US6381734B1 (en) | 1998-06-03 | 1998-06-03 | Method, software and apparatus for referencing a method in object-based programming |
| US89619 | 1998-06-03 |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| ES2230900T3 true ES2230900T3 (es) | 2005-05-01 |
Family
ID=22218650
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| ES99955342T Expired - Lifetime ES2230900T3 (es) | 1998-06-03 | 1999-06-03 | Referencia de un procedimiento en un programa basado en objetos. |
Country Status (7)
| Country | Link |
|---|---|
| US (1) | US6381734B1 (es) |
| EP (1) | EP1082654B1 (es) |
| JP (1) | JP4220127B2 (es) |
| AT (1) | ATE280973T1 (es) |
| DE (1) | DE69921474T2 (es) |
| ES (1) | ES2230900T3 (es) |
| WO (1) | WO1999063433A1 (es) |
Families Citing this family (33)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US6918126B1 (en) * | 2000-09-08 | 2005-07-12 | International Business Machines Corporation | Method and apparatus for creating and enforcing protected system level Java code |
| US7150001B1 (en) * | 2001-03-19 | 2006-12-12 | Microsoft Corporation | System and method to facilitate design-time component discovery |
| US6934946B2 (en) * | 2001-05-15 | 2005-08-23 | Sun Microsystems, Inc. | Lightweight native method invocation interface for java computing environments |
| US7152223B1 (en) * | 2001-06-04 | 2006-12-19 | Microsoft Corporation | Methods and systems for compiling and interpreting one or more associations between declarations and implementations in a language neutral fashion |
| US7636720B2 (en) * | 2003-05-08 | 2009-12-22 | Microsoft Corporation | Associating and using information in a metadirectory |
| US7634480B2 (en) | 2003-05-08 | 2009-12-15 | Microsoft Corporation | Declarative rules for metadirectory |
| US7257603B2 (en) * | 2003-05-08 | 2007-08-14 | Microsoft Corporation | Preview mode |
| US7516157B2 (en) * | 2003-05-08 | 2009-04-07 | Microsoft Corporation | Relational directory |
| US20040225632A1 (en) * | 2003-05-08 | 2004-11-11 | Microsoft Corporation | Automated information management and related methods |
| US7330853B2 (en) | 2003-05-08 | 2008-02-12 | Microsoft Corporation | Attribute value selection for entity objects |
| US7620658B2 (en) * | 2003-09-24 | 2009-11-17 | Microsoft Corporation | Configuration of a directory system |
| US7552450B1 (en) | 2003-09-30 | 2009-06-23 | Microsoft Corporation | Systems and methods for enabling applications via an application programming interface (API) to interface with and configure digital media components |
| US8533597B2 (en) * | 2003-09-30 | 2013-09-10 | Microsoft Corporation | Strategies for configuring media processing functionality using a hierarchical ordering of control parameters |
| US20070016292A1 (en) * | 2003-11-14 | 2007-01-18 | Edward Perez | Epithelium treatment methods and devices for treating the epithelium |
| US20050246773A1 (en) * | 2004-04-29 | 2005-11-03 | Microsoft Corporation | System and methods for processing partial trust applications |
| US7665062B1 (en) | 2004-07-02 | 2010-02-16 | Borland Software Corporation | System and methodology for design-time dynamic class type construction |
| US7561673B2 (en) * | 2004-09-30 | 2009-07-14 | Microsoft Corporation | Integration of speech services with telecommunications |
| US20070074185A1 (en) * | 2005-08-30 | 2007-03-29 | Microsoft Corporation | Identifier expressions |
| US7694285B2 (en) * | 2005-08-30 | 2010-04-06 | Microsoft Corporation | Relaxed and extended delegates |
| US9009688B2 (en) * | 2005-12-30 | 2015-04-14 | Intel Corporation | Type checking for object-oriented programming languages |
| US7752596B2 (en) * | 2006-03-17 | 2010-07-06 | Microsoft Corporation | Connecting alternative development environment to interpretive runtime engine |
| US7743087B1 (en) | 2006-03-22 | 2010-06-22 | The Math Works, Inc. | Partitioning distributed arrays according to criterion and functions applied to the distributed arrays |
| JP5359891B2 (ja) * | 2008-02-19 | 2013-12-04 | 日本電気株式会社 | 情報表示装置、方法及びプログラム |
| US8234626B2 (en) | 2008-06-04 | 2012-07-31 | Dell Products L.P. | Modular ASL component |
| US9569282B2 (en) * | 2009-04-24 | 2017-02-14 | Microsoft Technology Licensing, Llc | Concurrent mutation of isolated object graphs |
| US20110055809A1 (en) * | 2009-08-28 | 2011-03-03 | International Business Machines Corporation | Typed configuration management in programming languages |
| US20120159429A1 (en) * | 2010-12-15 | 2012-06-21 | Microsoft Corporation | Metadata based eventing |
| US8793706B2 (en) | 2010-12-16 | 2014-07-29 | Microsoft Corporation | Metadata-based eventing supporting operations on data |
| US20130212598A1 (en) * | 2012-02-14 | 2013-08-15 | Microsoft Corporation | Dependency informer |
| US9626171B2 (en) | 2015-07-24 | 2017-04-18 | Oracle International Corporation | Composing a module system and a non-module system |
| US10104090B2 (en) | 2015-08-25 | 2018-10-16 | Oracle International Corporation | Restrictive access control for modular reflection |
| US10394528B2 (en) | 2016-03-30 | 2019-08-27 | Oracle International Corporation | Returning a runtime type loaded from an archive in a module system |
| US10360008B2 (en) * | 2016-09-16 | 2019-07-23 | Oracle International Corporation | Metadata application constraints within a module system based on modular encapsulation |
Family Cites Families (26)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| AU639802B2 (en) * | 1990-08-14 | 1993-08-05 | Oracle International Corporation | Methods and apparatus for providing dynamic invocation of applications in a distributed heterogeneous environment |
| AU628264B2 (en) * | 1990-08-14 | 1992-09-10 | Oracle International Corporation | Methods and apparatus for providing a client interface to an object-oriented invocation of an application |
| US5265206A (en) * | 1990-10-23 | 1993-11-23 | International Business Machines Corporation | System and method for implementing a messenger and object manager in an object oriented programming environment |
| US5421016A (en) * | 1991-12-12 | 1995-05-30 | International Business Machines Corporation | System and method for dynamically invoking object methods from an application designed for static method invocation |
| US5515536A (en) * | 1992-11-13 | 1996-05-07 | Microsoft Corporation | Method and system for invoking methods of an object through a dispatching interface |
| US5632034A (en) * | 1993-06-01 | 1997-05-20 | International Business Machines Corporation | Controlling method invocation sequence through virtual functions in an object-oriented class library |
| DE69426143T2 (de) * | 1993-09-10 | 2001-06-13 | Sun Microsystems, Inc. | Kundenseitiger Stubinterpretor |
| US5732271A (en) * | 1995-01-23 | 1998-03-24 | International Business Machines Corporation | Data processing system and method for processing an object oriented development environment employing property inheritance using prototypical objects |
| US5680619A (en) * | 1995-04-03 | 1997-10-21 | Mfactory, Inc. | Hierarchical encapsulation of instantiated objects in a multimedia authoring system |
| DE19535519C2 (de) * | 1995-09-25 | 1999-03-04 | Ibm | Verfahren zur Reduzierung des Umfanges von Computerprogrammen |
| US5864862A (en) * | 1996-09-30 | 1999-01-26 | Telefonaktiebolaget Lm Ericsson (Publ) | System and method for creating reusable components in an object-oriented programming environment |
| US6298476B1 (en) * | 1995-12-04 | 2001-10-02 | International Business Machines Corporation | Object oriented software build framework mechanism |
| US5768505A (en) * | 1995-12-19 | 1998-06-16 | International Business Machines Corporation | Object oriented mail server framework mechanism |
| US6104874A (en) * | 1996-10-15 | 2000-08-15 | International Business Machines Corporation | Object oriented framework mechanism for order processing including pre-defined extensible classes for defining an order processing environment |
| US6002867A (en) * | 1996-10-24 | 1999-12-14 | Inprise Corporation | Development system with methods providing visual form inheritance |
| US5937189A (en) * | 1996-11-12 | 1999-08-10 | International Business Machines Corporation | Object oriented framework mechanism for determining configuration relations |
| US5991802A (en) * | 1996-11-27 | 1999-11-23 | Microsoft Corporation | Method and system for invoking methods of objects over the internet |
| US5920720A (en) * | 1997-02-25 | 1999-07-06 | Microsoft Corporation | Efficient computer based virtual machine object structure |
| US6182274B1 (en) * | 1997-05-01 | 2001-01-30 | International Business Machines Corporation | Reusing code in object-oriented program development |
| US5941945A (en) * | 1997-06-18 | 1999-08-24 | International Business Machines Corporation | Interest-based collaborative framework |
| US6014710A (en) * | 1997-06-30 | 2000-01-11 | Sun Microsystems, Inc. | System and method for message transmission between network nodes using remote wires |
| US6078743A (en) * | 1997-11-24 | 2000-06-20 | International Business Machines Corporation | Generic IDE interface support for scripting |
| US6199197B1 (en) * | 1998-03-11 | 2001-03-06 | International Business Machines Corporation | Apparatus and method for providing common behavior across different processing levels in an object oriented framework |
| US6195791B1 (en) * | 1998-03-11 | 2001-02-27 | International Business Machines Corporation | Object mechanism and method for coupling together processes to define a desired processing environment in an object oriented framework |
| US6275979B1 (en) * | 1998-03-11 | 2001-08-14 | International Business Machines Corporation | Implementation for an object oriented run-time extensible item |
| US6083276A (en) * | 1998-06-11 | 2000-07-04 | Corel, Inc. | Creating and configuring component-based applications using a text-based descriptive attribute grammar |
-
1998
- 1998-06-03 US US09/089,619 patent/US6381734B1/en not_active Expired - Lifetime
-
1999
- 1999-06-03 EP EP19990955342 patent/EP1082654B1/en not_active Expired - Lifetime
- 1999-06-03 ES ES99955342T patent/ES2230900T3/es not_active Expired - Lifetime
- 1999-06-03 DE DE69921474T patent/DE69921474T2/de not_active Expired - Lifetime
- 1999-06-03 WO PCT/US1999/012299 patent/WO1999063433A1/en active IP Right Grant
- 1999-06-03 AT AT99955342T patent/ATE280973T1/de active
- 1999-06-03 JP JP2000552579A patent/JP4220127B2/ja not_active Expired - Fee Related
Also Published As
| Publication number | Publication date |
|---|---|
| DE69921474D1 (de) | 2004-12-02 |
| DE69921474T2 (de) | 2006-01-05 |
| EP1082654B1 (en) | 2004-10-27 |
| EP1082654A1 (en) | 2001-03-14 |
| WO1999063433A1 (en) | 1999-12-09 |
| JP4220127B2 (ja) | 2009-02-04 |
| US6381734B1 (en) | 2002-04-30 |
| ATE280973T1 (de) | 2004-11-15 |
| JP2002517815A (ja) | 2002-06-18 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| ES2230900T3 (es) | Referencia de un procedimiento en un programa basado en objetos. | |
| Johnsen et al. | ABS: A core language for abstract behavioral specification | |
| EP3170073B1 (en) | Variable handles | |
| Noble et al. | Flexible alias protection | |
| Johnsen et al. | Creol: A type-safe object-oriented model for distributed concurrent systems | |
| EP0546683B1 (en) | Language neutral objects | |
| EP0735474B1 (en) | Method and apparatus for generation and installation of distributed objects on a distributed object system | |
| Saraswat | Java is not type-safe | |
| EP0546684A2 (en) | Method stubs for redispatch | |
| JP2005530238A (ja) | 動的モデル／コード結合を提供するシステム、方法、および媒体 | |
| VanHattum et al. | Verifying dynamic trait objects in Rust | |
| Eugster | Uniform proxies for Java | |
| Börger et al. | Modular design for the Java virtual machine architecture | |
| Greenhouse | A programmer-oriented approach to safe concurrency | |
| Eisenbach et al. | Changing Java Programs | |
| Mohanty et al. | Basic solidity programming | |
| Johnsen et al. | A dynamic binding strategy for multiple inheritance and asynchronously communicating objects | |
| Chisnall | A Modern Objective-C Runtime. | |
| Lewis | Producing network applications using object-oriented petri nets | |
| Savinov | Concept-oriented programming: from classes to concepts and from inheritance to inclusion | |
| Anderson et al. | Implementing Fickle | |
| Buckley | Ownership types restrict aliasing | |
| Zimmerman et al. | Latte: Lightweight Aliasing Tracking for Java | |
| Rintala | Techniques for Implementing Concurrent Exceptions in C++ | |
| Tardieu et al. | Shim: A deterministic approach to programming with threads |