| ||
Advanced Issues: Object Metamorphosis |
Object metamorphosis, dynamic changes to the structure of already existing objects, is a powerful, new tool in the design of object-oriented programs using strongly typed languages. CLOS has supported dynamic object structure evolution for many years. It does not take that much magic to change the memory layout and contents of an object, the problem is to integrate such a facility into a strongly typed language, hence obtaining some safety guarantees. The combination of dynamic changes of object structure and strict, static type-checking is available in gbeta, using a syntax which is already known from assignments of type variables, namely:
anObject . This
mechanism is called dynamic specialization.
The result of applying a type constraint to an object is that its
structure is enhanced in such a way that it can be described by both
the type which this object used to have (until now), and by the type
which is applied as a constraint. In other words, an object
The type of an object can grow more special (it can become more "derived", obtain more attributes or specialize existing ones), never more general. The reason is that it would be very expensive and messy to ensure type-correctness in a program if any object were allowed to lose already acquired attributes. Generally, allowing for the possibility that any object might answer "message not understood" would of course not be acceptable in a typed language. To handle attribute lossage, it might be possible to revoke references with a not-longer-supported declared type (weak pointers), but making all references in all programs weak would not be acceptable either. Consequently, objects can only become more special.
There is another special constraint on the usage of dynamic
specialization, namely that it can only be applied to objects which
are created dynamically (normally using the What could this be used for?One interesting usage for this is to reduce the number of combination classes needed when using multiple inheritance. If you have ten classes which can be meaningfully combined, then you might have a hard time keeping track of the myriad of possible combinations that somebody might want. Just declaring all possible combinations in some globally accessible file would not be feasible. With the dynamic specialization in gbeta, you would just declare the ten patterns and let the users of those classes build their combined objects as they need them. In a complex project where several independent teams are supplying the different base patterns, there would be no need for a "hub" in the code which depends on all of them, you just include the three you need right now. Moreover, when giving the object to another subsystem, that subsystem might enhance the structure with some other aspects that you don't have to know about. As a result, a greater separation of concerns is achieved. Another way to use it is to support a notion of roles and role-players, as described later. Example 1Here's an example:
The next section is about method combination. |