Data processing: software development – installation – and managem – Software program development tool – Programming language
Reexamination Certificate
1999-05-24
2002-11-26
Dam, Tuan Q. (Department: 2122)
Data processing: software development, installation, and managem
Software program development tool
Programming language
C717S154000, C717S165000, C709S241000
Reexamination Certificate
active
06487714
ABSTRACT:
FIELD OF THE INVENTION
This invention relates to object-oriented programming and particularly to an object's method execution during run-time.
BACKGROUND OF THE INVENTION
In class-based Object orientated Programs such as C++ and Java, a “class” is a template that defines an object's methods and variables. A class can have sub-classes that can inherit some or all of the characteristics of the class. Subclasses can defines new methods that are not themselves defined in the parent class. It is sometimes desirable to have different implementations of an object's methods within a single system where the choice of implementation depends upon various dynamic run-time, attributes, e.g. different implementations for sparse and dense matrices. To some extent, this can be achieved by sub-classing; however, sub-classing cannot be used to change the behavior of an existing object. Further, sub-classing requires explicit programmer action to determine the type of object to create.
By way of specific example, consider distributed object-based systems that often use proxies to represent remote objects. When a client invokes a method on the proxy, the code found at the method's entry in the virtual method table will redirect the invocation to the master object at the server. Proxies can perform various types of caching; however, all instances of a proxy for a particular class of remote object perform the same caching algorithm. In addition, proxies are not transparent to the programmer: a user can typically tell the difference between the run-time type of the proxy and the master object (if the language being used allows determination of an object's run-time type). Further, if an object migrates, the source node cannot continue using its existing references to the object; changing the implementation of an object from master to proxy requires changing the identity of the object (as well as its run-time type) Finally, since all proxies for a given class typically execute the same code, there is no way for the system to customize the behavior of a particular instance of a proxy at run-time based upon changing resource characteristics of the executing platform.
Aspects of the problem have been addressed in the art, albeit not entirely satisfactorily. For example, the “Smalltalk” language includes the ability to exchange one object with another using the symmetric definition of the “become:” message, such that:
a become: b
causes all pointers to object “a” to point to object “b”, and vice versa. This is the original definition of “become:”. The asymmetric or one-way definition was added later in order to preserve compatibility between older versions of Smalltalk, where object pointers were indices placed into an indirection table. The implementation of “become:” merely required swapping pointers in the table. For later implementations not based on the indirection table, the implementation of “become:” required scanning all the memory for pointers to the first object. Therefore, these later implementations generally opted for the asymmetric semantics, wherein the definition of “b” is unchanged. Thus, all pointers to object “a” will now point to object “b” and all (old) pointers to object “b” remain unchanged.
In any case, it is not clear how to ensure consistency between the two definitions in a multithreaded environment. Further, use of a specific implementation of “become” in an application is not orthogonal to the application but, rather, requires explicit programmer intervention. Also, it does not change the implementation for an existing object, but rather changes the object referred to by a particular reference. Whilst this can be used to obtain some of the effect of changing the implementation of an existing object, it requires the program explicitly to construct the new object which is to be the replacement. Finally, objects with different implementations have different run-time types.
In chapter 10 of “Advanced C++” by James O. Coplien, there is described a mechanism known as Dynamic Multiple Inheritance for dynamically setting how an object is created. The idea presented is that the implementation of the new operator contains a switch statement, which according to the value of the variable will determine which implementation to use for an object. The variable is passed to new as a parameter. By employing this mechanism, the program instantiates the required type depending on the run-time value of the variable.
However, it is to be noted that once an object is created, its implementation is fixed for the lifetime of the object. Furthermore, the manner in which the switch variable is passed to new is not transparent to the programmer who must provide the implementation for passing the desired variable. Finally, the run-time type of the object differs based upon the implementation picked by the new operator.
In the Self language, an object can change its behavior many times during run-time but in each case it is considered a different object. Unlike languages based on the use of “classes” and their “instances”, Self is based on the prototype concept. In Self, a program starts with an initial set of prototype objects, which are true objects in the classical sense. An application programmer needing another object with certain properties, chooses the prototype “nearest” to the required one, copies it and changes the data slots (fields) and method slots as required. Thus, an object is not an instance of a class (prototype), but rather is a copy of a prototype or a different object altogether. In a vanilla object-oriented language like C++ or Java, the behavior of the object is fixed and all objects of the same class implement the same methods in the same way and thus exhibit the same behavior. It would clearly be desirable to adapt such a language so as to allow the behavior of an object to be changed dynamically during run-time, whilst maintaining the fact that the object is an instance of the same class all the time. At the same time, different instances of the same class having different implementations at any particular instance in time must be allowed.
SUMMARY OF THE INVENTION
It is an object of the invention to provide a data structure and associated mechanism for implementing an object oriented programming language, which allows different implementations of a method to be executed dynamically during run-time, without requiring instantiation of an object of a different class.
According to a first aspect of the invention, there is provided a data structure and associated mechanism for implementing object oriented programming language, comprising:
at least two code blocks for at least one method of an object of a specified class, each of said code blocks containing a different implementation of said at least one method, and
an access mechanism for accessing a desired code block at run-time on a per object instance basis so as to allow selection of a desired implementation of said at least one method without requiring instantiation of an object of a different class;
said selection of which implementation to invoke being integrated into an existing invocation method of said language and thus being transparent to a calling application invoking said at least one method.
According to a second aspect of the invention, there is provided a method for implementing an object oriented programming language, comprising:
(a) providing at least two code blocks for at least one method of an object of a specified class, each of said code blocks containing a different implementation of said at least one method, and
(b) accessing a desired code block at run-time on a per object instance basis so as to allow selection of a desired implementation of said at least one method without requiring instantiation of an object of a different class;
said selection of which implementation to invoke being integrated into an existing invocation method of said language and thus being transparent to a calling application invoking said at least one method.
The invention des
Azagury Alain Charles
Factor Michael
Porat Sara
Teperman Avi
Browdy and Neimark , P.L.L.C.
Dam Tuan Q.
Kendall Chuck
LandOfFree
Mechanism for dynamic selection of an object's method does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with Mechanism for dynamic selection of an object's method, we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Mechanism for dynamic selection of an object's method will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-2980503