In most object-oriented languages, behavior cannot be specialized. Let us rst consider a non-example. Typically, the behavior of a method m (in some lan-guages it must be `virtual') in a given classCcan be made dierent from what it is in the superclass(es) of C by overriding the implementation of m with a
dierent one. The new implementation is generally written from scratch. Only ordinary method invocations may be used to produce a new behavior built on the existing behaviors, for instance by invoking the implementation of m in a specic superclass (as withsuperOfC::m()in C++) or by sending a message to a special object designator like `super' (as in Smalltalk) which will invoke the implementation available in the immediate superclass.
It may seem natural to include method overriding into the concept of be-havior specialization, but it is not the same. Method overriding will make an invocation ofmexhibit dierent behavior when invoked on instances of dierent classes, but the implementations ofm will not be a family of related methods which are dened incrementally; the dierent implementations ofmare entirely independent methods which are only brought together by the common name.
In contrast, a family of methods related by behavioral specialization is more like a class hierarchy, where commonalities in behavior are factored out into the general members of the family, and more special members are created in-crementally from more general ones. As a special case, such a family of related methods may be used as the implementations of a virtual method, but it may also be used in other ways.
Specialization of behavior is available in Beta, as presented already in in [60], and it is available in a generalized form in gbeta. In both Beta and gbeta, specialization of behavior is based on theINNERimperative. INNERworks the same inBetaandgbeta, at least when describing patterns as lists of mixins, as it was done in the previous sections. The only dierence is thatgbetaallows for much more exible ways to create patterns from given mixins. As shown in Sect. 3.8.2, this makes a real dierence in expressive power.
Behavior specialization is the creation of a more rened, detailed, complex behavior from a less rened one by means of an incremental specication. For example, yelling di-bah-ba-doo-dah-dosh is a specialized version of the behav-ior of yelling ba-dooh-dah, but also a specialized version of yelling di-bah-[]-dosh, where [] is a special placeholder which by the rules of the game may be replaced by anything, and which defaults to nothing if it does not get replaced.
3.8. SPECIALIZATION OF BEHAVIOR 69 Actually, both of the less special behaviors may be viewed as the general basis from which the special behavior is derived, using the other, less special behavior as an incremental specication. However, the behaviors cannot just be added symmetrically, there must be a specication of how to combine them.
Kristine Stougaard Thomsen created a proposal for how behavior could ac-tually be combined in a mostly symmetrical manner by means of non-sequential execution (similar to coroutines) already in 1987 [108]. The central concept in this proposal is that the INNERimperative is replaced with another construct which would transfer the control to another do-part, thereby allowing several equally specic mixins to coexist without having to decide on an ordering. This idea might well be applied in context of the generalized merging mechanism.
However, we believe that the programmer in the general case would have too much trouble determining exactly what would happen at run-time with such a cross-over mechanism instead of INNER, so it is our impression that it should preferably be used only in those cases where thedo-parts in question could really be executed in an arbitrarily interleaved order.
Together, the notion of patterns as lists of mixins (not sets of mixins), in-heritance, the pattern merging operation, and the INNERimperative provide a rich framework for creating and using combinations of behavior specications in gbeta. The specialization of behavior which this gives rise to will now be described in two phases, rst from above considering patterns and behaviors as a whole, then from below considering the individual mixins and their DoParts.
3.8.1 Specialization of Behaviora Top-Down View
The behavior associated with a pattern will be present as an aspect of the behavior of any of its subpatterns; it can never be discarded, only rened. This ensures that a subpattern will always have a behavior which is in some sense a completion and enhancement of the behavior of each of its superpatterns.
The behavioral specialization relation is based on syntactical criteria, so there is no consistent, bullet-proof semantic meaning behind the claim that
`behavior cannot be discarded'; in contrast, it is actually possible to add a mixin to a pattern P such that the resulting pattern will do what the new mixinDoPartspecies, ignoring the behavior ofP entirely. An example of this kind of distorted behavioral specialization is the following:
(* original behavior *) do 'Hello, world!'->stdio;
(* "refined" behavior *)
do (if false then 'Hello, world!'->stdio if);
'Good day, earth!'->stdio; Ex.
3-6
The rened version of the code is in fact built from the existing behavior and a new contribution, but the semantics of the execution ensures that only the new behavior will be observed. As a general rule, though, a subpattern will have a behavior which can reasonably be described as a specialization of the
p: (# do (for i:3 repeat INNER for)#);
q: p(# (* fill in the INNER of p *) do 'Hello, world!'->stdio
#);
r: (# (* print 'Hello, world!' three times *) do (for i:3 repeat
'Hello, world!'->stdio for)
#)
i:3 INNER for
'Hello, world!'->stdio
Figure 3.8: Specialization of behavior: qandrare equivalent
behavior of any of its superpatterns. In particular, this is a meaningful goal which programmers may strive for and generally achieve.
Like gbeta, Beta also supports a syntacticnot a semanticbehavioral specialization relation; but it would not be easy to improve that into a genuine semantic renement relation. It would be hard to formalize `behavioral special-ization', and it would surely be an undecidable problem to verify it statically for a non-trivial language. Hence, a syntactic approximation is probably the best we can hope for. Of course, run-time checks of assertions like the pre- and post-conditions of Eiel can be added, and there has been a framework for doing this in Beta, to a certain extent, for several years. We should note that pre-and post-conditions pre-and invariants in Eiel express these correctness criteria as part of the interface and thereby elevate them to a more visible position than they could have as part of method implementations. This is likely to strengthen the consciousness of programmers about these criteria and thereby support the creation of high quality systems.
However, support for provable behavioral conformance is not the basic idea behind theBetaandgbetabehavioral specialization mechanisms, the basic idea is rather to enable incremental specication of behavior. That is an obvious goal given the relation between concepts and patterns, and given the existence of specialization relations between concepts. Admittedly, the mechanical spe-cialization relation supported by Beta and gbetaare very crude imitations of the specialization relations in natural language. But they are indeed useful!
3.8.2 Specialization of Behaviora Bottom-Up View
The behavior specialization process can be described as a syntax tree completion process, i.e., as a source code transformation which inserts entireDoParts from more specic mixins into special positions (INNERimperatives) in less specic ones. This transformation process correctly shows which imperatives will be executed in what order, and it promotes the right idea about specialization as a process of lling-in missing pieces; however, the transformations generally
3.8. SPECIALIZATION OF BEHAVIOR 71 change the name binding environments of names, so they could not be performed on real programs without changing their semantics ormore likelyintroducing static semantic errors.
Nevertheless, these transformations will be used to illustrate the behavior combination mechanism, starting with the example in Fig. 3.8 which happens to work correctly also after the transformation. In the gure, the patternpis the general basis whose behavior is to repeatINNERthree times, and the denition of q adds an increment to the behavior of p, thereby determining what the meaning of INNER in p is. As a result, the behavior of q is equivalent to the behavior of r.
From the concrete example we turn to an informal but general, recursive denition: The behavior of object, the empty list of mixins, is to do nothing.
The behavior of a pattern containing just one mixin is theDoPartof that mixin.
The behavior of a pattern with at least two mixins is derived from the behavior of its tail (which is the same as the immediate superpattern inBeta) by inserting the behavior of the head into each occurrence of an INNER imperative in the behavior of the tail.
The behavior of aDoPartis the eect of executing the imperatives in that DoPart in context of a part object which is an instance of a mixin associated with the enclosing MainPart. The insertion of a behavior into an occurrence of
INNERis a transfer of control similar to a sub-routine call, i.e., a jump to the DoPart in question, followed by the execution of the imperatives there, in the environment of the corresponding part object, and returning from thatDoPart upon termination.
An alternative explanation of the semantics of theINNERis that it is similar to a message send to superin Smalltalk, but it calls the subclass (the next more specic mixin, i.e., the preceding element in the pattern) instead of the superclass (the next more general mixin, i.e., the successor element). Thinking of INNERas an `invertedsupersend' might seem to be the most direct approach at rst, but the view of the syntax tree being completed gradually by lling in the INNERplaceholders with the DoPart from the next more special mixin is closer to the intention behind the mechanism. Again, Beta and gbeta have exactly the same semantics of INNERfor any given pattern, butgbetawill allow a more exible construction of patterns from existing mixins.
Figure 3.9 on page 72 is an example where combinations of a few mixins into several dierent patterns show dierent behavior as determined by the semantics of INNER(note that the booleandoitisfalseat the beginning of each imperative). For example, the mergingc&b&agives rise to the equivalent of the following DoPart:
do (for 4 repeat 'c'->stdio;
(not doit)->doit;
(if doit then 'b'->stdio
else true->doit; 'a'->stdio; false->doit if)
for) Ex.
3-7
(# doit: @boolean;
a: (# do true->doit; 'a'->stdio; INNER; false->doit #);
b: (# do (if doit then 'b'->stdio else INNER if)#);
c: (# do (for 4 repeat
'c'->stdio; (not doit)->doit; INNER for)
#)
do a; (* prints 'a' *)
b; (* prints '' *)
c; (* prints 'cccc' *)
a&b; (* prints 'ab' *)
b&a; (* prints 'a' *)
a&c; (* prints 'acccc' *) c&a; (* prints 'cacacaca' *) b&c; (* prints 'cccc' *) c&b; (* prints 'cbccbc' *) a&b&c; (* prints 'ab' *) a&c&b; (* prints 'accbccb' *) b&a&c; (* prints 'acccc' *) b&c&a; (* prints 'cacacaca' *) c&a&b; (* prints 'cabcabcabcab' *) c&b&a; (* prints 'cbcacbca' *)
#)
Figure 3.9: Many examples of specialization of behavior
Of course, a systematic enumeration of the possible combinations like this ex-ample does not make sense in a real usage context, but some of the combinations are examples of more generally applicable principles. For example, try to com-parec&awitha,c&a&bwitha&b, andc&bwithb; this shows the usage of cas a behavioral aspect which will repeat whatever it is combined with, and modify the environment in which the repeated behavior is executed (by changingdoit).
Similarly,bis a conditionalizing behavioral aspect which chooses whether or not to execute whatever behavior it is combined with. This is demonstrated by c&b&a, where b uses adierently for each iteration of the for-imperative, depending on the environmentwhich is controlled by c. Mixins similar to
b can be used to switch on and o the behavior of given patterns, according to whatever criteria are appropriate. Clearly, a given basic behavior enhanced with the ability to be switched on and o may be described as a rened, spe-cialized version of the basic behavior itselfalthough the conditionalizing mixin arguably plays the role of a post-hoc added superpattern when considered from aBetapoint of view.
These kinds of behavioral specialization which include the placement of a given, comparatively simple super behavior in the context of some other
in-3.9. OBJECT CREATION 73