There have been various proposals for separating an interface from an implementation. For example the language Java supports this separation . An Interface defines a set of method signatures, while a Class defines the structure and behavior of its instances. A class may match several interfaces, if it implements the methods defined by each interface. Classes are instantiable, while interfaces are not. In contrast, we propose a different separation of interface and implementation, based on the properties supported by the context relation. A base class defines the structure and interface (method signatures) of its instances, and may provide implementations for the interface as well. If an implementation of a method is not provided directly in the base class, the implementation may be separately given in one or more classes that are context-related to the base class. In contrast to the notion of Interface in Java, a base class that defines only interfaces may still be instantiated. To prevent a method resolution error at run-time, we require an implementation of the method to either exist directly in the base class or to exist in some context-related class that is declared to be the default implementation, as in Figure 5.
In C++, dynamic binding is required when a virtual method is invoked through a pointer. In a language such as Java , all methods are assumed virtual (unless declared final) and all objects are referenced through pointers. The context relation allows method update, not just for subclasses but for the base class itself. Dynamic binding occurs regardless of whether a method is invoked through a pointer or variable. We propose the use of context tables, a dynamic version of static virtual function tables, to avoid pointer chasing through lists of context objects. The use of the tables will support fast method lookup. For simplicity, we assume all methods to be context-updatable, although it would be possible to add a keyword to limit dynamic lookup such as the final keyword in Java.
A metaobject protocol (MOP) is an interface that allows a programmer to
customize properties of the programming language, such as adding persistence
and concurrency [2,11]. A reflective programming language
is one which supports such customizations, allowing the program to reason
about its own execution state and alter behavior
accordingly . The context relation and context objects
can be implemented using reflection.