These problems are solved in the MOP of Guaranį by splitting the meta-level processing associated with a base-level operation in the following steps:
Replacement operations can be created in the meta-level using operation factories, that allow meta-objects to obtain privileged access to the base-level objects they manage. Using operation factories, stand-alone operations can also be created and performed, i.e., submitted for interception, meta-level processing and potential delivery for base-level execution.
We have been able to define composers by separating operation handling from result handling, implemented in two distict methods, namely, handle operation and handle result. A composer is a meta-object that delegates operations and results to multiple meta-objects, then composes their replies in its own replies. For example, a composer can implement the chain of meta-objects presented before, but in a way that one meta-object does not have to keep track of its successor. Another implementation of composer may delegate operations and/or results concurrently to multiple meta-objects, or refrain from delegating an operation to some meta-objects if it is aware they are not interested in that operation.
In Guaranį, at any given moment, each object can be associated with at most one meta-object, called its primary meta-object. If there is no such association, operations addressed to that object are not intercepted, and we say that the object is not reflective at that moment.
The fact that Guaranį associates a single (primary) meta-object with an object keeps the design of the interception mechanism simple. Since the primary meta-object can be a composer, as can any meta-object it delegates to, multiple meta-objects can reflect upon an object. These meta-objects form what we call the meta-configuration of that object, a potentially infinite hierarchy of composition that is orthogonal to the well-known infinite tower of meta-objects [4].