The Reflective Architecture of Guaraná

Several run-time MOPs have been designed so that, when a meta-object is requested to handle a reified operation (for example, a method invocation), it is obliged, by design of the MOP, to return a valid result for the operation. The meta-level computation that yields the result can include or not the delivery of the operation to the base-level object.

This design implies that the only way to combine the behavior of meta-objects is by arranging for one meta-object, say M, to forward operation handling requests to another, say N, delegating to N the responsibility for computing the result of the operation. Only after N returns a result will M be able to observe and/or to modify it.

Given such a protocol, meta-objects are likely to be organized in a chain, so that each meta-object delegates operation handling requests to its successor. The last element of the chain is either the base-level object [2] or a special meta-object that delivers operations to it [6]. We argue that this design presents some serious drawbacks:

• it is intrusive upon the meta-object implementation, in the sense that a meta-object must explicitly forward operations to its successor;

• it forbids multiple meta-objects from concurrently handling the same operation, because, at a given moment, at most one meta-object can be responsible for producing a result or delivering the operation to the base level;

• it forces meta-objects to receive the results of operations they handled, even if they are not interested in them;

• the order of presentation of results is necessarily the reverse order of the reception of operations, even though different (possibly concurrent) orderings might be more appropriate or efficient, according to the semantics of the application.