next up previous
Next: Propagation of meta-configurations Up: The Meta-level Protocol of Previous: Composers

Meta-configuration management


  
Figure 4: Reconfiguring an object's meta-configuration
\begin{figure*}
\begin{center}
\par\setlength{\unitlength}{0.00083333in}
\be...
...ecomes the primary meta-object of object \textsf{o}.
\end{quote}
\end{figure*}

When an application starts up, every object has an empty meta-configuration, that is, no object is subject to reflection. The application may create objects and meta-objects, then associate them, by requesting the kernel of Guaranį to reconfigure the object's meta-configuration with a given meta-object.

When a reconfiguration request is issued on a reflective object, i.e., one that already has a non-empty meta-configuration, its existing meta-configuration is requested to determine the new meta-configuration, based on itself and on the requested meta-configuration. It may either (i) allow a complete replacement of itself with the suggested meta-configuration, (ii) reject any modifications, (iii) incorporate the suggested meta-configuration, or (iv) create a completely new meta-configuration, as depicted in Figure 4. Note that, when the kernel invokes the method reconfigure of the primary meta-object, it passes the primary meta-object itself as an argument. This signals the meta-object it is the root of the reconfiguration that should take place.

If the object whose meta-configuration was to be reconfigured had an empty meta-configuration, a message with the object and its suggested meta-configuration will be broadcast to the meta-configuration of the object's class, whose meta-objects may modify the meta-configuration to be used. The message will also be broadcast to all superclasses of the object's class, so that any class will be able to reject or modify reconfiguration requests of its previously non-reflective instances.

In addition to a mechanism to replaces the whole meta-configuration of an object, the kernel of Guaranį provides an additional method that allows the caller to specify which meta-object should be looked for and replaced. This reconfiguration request traverses the meta-configuration just like a broadcast message. Each meta-object should check whether it is the root of the meta-configuration, and decide what to do with regard to the reconfiguration request accordingly. A meta-object that is not the root of the meta-configuration request will usually ignore it, returning itself. However, one that is the root should behave just like the primary meta-object in Figure 4. Thus, in order to be able to replace a meta-object, it is not necessary to know whether it is the primary meta-object or if some composer refers to it.



 
next up previous
Next: Propagation of meta-configurations Up: The Meta-level Protocol of Previous: Composers
contact the authors