next up previous
Next: Support for proxy objects Up: The Reflective Architecture of Previous: The Reflective Architecture of

Meta-configuration management

Guaranį presents two additional features that enforce the separation of concerns between the base level and the meta level: (i) the meta configuration of an object is completely hidden from the base level and even from the meta level itself; and (ii) the initial meta-configuration of an object is determined by the meta-configurations of its creator and of its class, a mechanism we call meta-configuration propagation.

The first design decision implies that there is no way to find out what is the primary meta-object associated with an object. It is possible, however, to send arbitrary messages and reconfiguration requests to the components of the meta-configuration of an object, through the kernel of Guaranį.

Messages can be used to extend the MOP of Guaranį, as they allow meta-objects to exchange information even if they do not hold references to each other. Meta-objects that do not understand a message are supposed to ignore it, and composers are expected to forward messages to their components, as in Figure 5. The kernel operation that implements this mechanism is called broadcast.


  
Figure 5: Broadcasting a message.
\begin{figure}{\small\begin{center}\fbox{ \begin{picture} (210,120)(0,-20) \pu... ...x{Guarana.broadcast(O,M);\par } } } \end{picture} }\end{center}} \end{figure}

Any object M (for message) can be sent to the primary meta-object of an object O. Composers usually forward messages to their components. For non-reflective objects, this request is ignored.


  
Figure 6: Dynamic reconfiguration.
\begin{figure}{\small\begin{center}\fbox{ \begin{picture} (210,123)(0,-22) \pu... ...reconfigure(O,MO$_3$ ,MO$_6$ ); } } \end{picture} }\end{center}} \end{figure}

A request to replace MO3 with MO6 in the meta-configuration of O was issued. As the request descends the composition hierarchy, it reaches the target meta-object. In this case, it agrees to be replaced, by returning the proposed meta-object. A meta-object must return itself in order to ignore the request, as C1 does, otherwise the returned meta-object will replace it.

A reconfiguration request (Figure 6) carries a pair of meta-objects, suggesting that the first meta-object (MO3) should be replaced with the second (MO6) in the meta-configuration of object O. A special value (null) can be used to refer to the primary meta-object. It is up to the existing meta-configuration to decide whether the request is acceptable or not. However, if the base-level object is not reflective, an InstanceReconfigure message is broadcast to the meta-configurations of its class and of its superclasses, as depicted in Figure 7. Their components can modify the suggested meta-configuration, for example, forcing it to remain empty.


  
Figure 7: Reconfiguration of a non-reflective object.
\begin{figure}{\small\begin{center}\fbox{ \begin{picture} (210,150)(0,-50) \par... ...circle{2}} \put(9,-6){{\tiny MO}} } \end{picture} }\end{center}} \end{figure}

The null meta-object can be used as an alias for the primary meta-object in reconfiguration requests. When the object is not reflective, the meta-configuration of its class will be given the opportunity to affect the proposed meta-configuration of the instance. An InstanceReconfigure message will carry the proposed meta-object, so that meta-objects of the object's class(es) may modify it. The remaining meta-object will become the object's primary meta-object.

In most object-oriented programming languages, creating an object consists of two steps: (i) allocating storage for the object, possibly initialized with default values, then (ii) invoking its constructor. We say that these steps are performed by the creator of the object.

Meta-configuration propagation takes place between these two steps in Guaranį. The primary meta-object of the creator is responsible for providing a meta-object for the new object. It may return null, a different meta-object or even itself, as a meta-object can belong to multiple meta-configurations. A composer is expected to forward this request to its components and to create a composer that delegates to the meta-objects returned by them, as in Figure 8.


  
Figure 8: Meta-configuration propagation.
\begin{figure}{\small\begin{center}\fbox{ \begin{picture} (210,155)(-10,-50) \p... ... \dottedline[.]{3}(29,-14)(49,-7) } \end{picture} }\end{center}} \end{figure}

When a reflective object instantiates another object, its meta-configuration may propagate to the new object before the object is initialized. In fact, the meta-configuration does not have to propagate as a whole: in the picture, only MO3 was effectively propagated; MO2 was discarded, whereas MO1 named MO4 to occupy its place in the meta-configuration of the new object. C1 created a new composer to delegate to MO4 and MO3.

After meta-configuration propagation, the kernel of Guaranį broadcasts a NewObject message to the meta-configuration of the class of the new object, so that its meta-objects can try to reconfigure it, as shown in Figure 9. Finally, the object is constructed, but the constructor invocation will be intercepted if the new object has become reflective.


  
Figure 9: NewObject messages.
\begin{figure}{\small\begin{center}\fbox{ \begin{picture} (210,85)(25,-50) \par... ...\tiny Object}} \end{picture}} } \par \end{picture} }\end{center}} \end{figure}

After meta-configuration propagation, the meta-configuration of the class of a new object is notified about the new instance, with a NewObject message, so that it can try to affect the meta-configuration of its instances, by issuing reconfiguration requests.

next up previous
Next: Support for proxy objects Up: The Reflective Architecture of Previous: The Reflective Architecture of
contact the authors