$30.3 FROM PROCESSES TO OBJECTS 959 All this is fine for processes,the concurrent equivalent of traditional sequential programs which"do one thing";indeed,a concurrent system built with processes is like a sequential system with several main programs.But in the object-oriented approach we have rejected the notion of main program and instead defined software units that stand ready to provide any one of a number of possible features. Reconciling this view with the notion of process requires elaborate synchronization constructs to make sure that each supplier is ready to execute a feature when the client needs it.The reconciliation is particularly delicate when both client and supplier are active objects,since each has its own agenda. All this does not make it impossible to devise mechanisms based on the notion of active object,as evidenced by the abundant literature on the subject (to which the bibliographical notes to this chapter give many references).But this evidence also shows the complexity of the proposed solutions,of which none has gained wide acceptance, suggesting that the active object approach is not the right one. Active objects clash with inheritance Doubts about the suitability of the active object approach grow as one starts looking at how it combines with other O-O mechanisms,especially inheritance. If a class B inherits from a class 4 and both are active (that is to say,describe instances that must be active objects),what happens in B to the description of's process? In many cases you will need to add some new instructions,but without special language mechanisms this means that you will almost always have to redefine and rewrite the entire process part-not an attractive proposition. See“Sequencing Here is an example of special language mechanism.Although the Simula 67 and inheritance'”, language does not support concurrency,it has a notion of active object:a Simula class can, page 1121,as part of the discussion of besides its features,include a set of instructions,called the body of the class,so that we Simula. can talk of executing an object-meaning executing the body of its generating class.The body of a class 4 can include a special instruction inner,which has no effect in the class itself but,in a proper descendant B,stands for the body of B.So if the body of4 reads some initialization,inner,some termination actions and the body of B reads specific B actions then execution of that body actually means executing some initialization;specific B actions,some_termination_actions Although the need for a mechanism of this kind is clear in a language supporting the notion of active object,objections immediately come to mind:the notation is misleading, since if you just read the body of B you will get a wrong view of what the execution does; it forces the parent to plan in detail for its descendants,going against basic O-O concepts (the Open-Closed principle);and it only works in a single-inheritance language.§30.3 FROM PROCESSES TO OBJECTS 959 All this is fine for processes, the concurrent equivalent of traditional sequential programs which “do one thing”; indeed, a concurrent system built with processes is like a sequential system with several main programs. But in the object-oriented approach we have rejected the notion of main program and instead defined software units that stand ready to provide any one of a number of possible features. Reconciling this view with the notion of process requires elaborate synchronization constructs to make sure that each supplier is ready to execute a feature when the client needs it. The reconciliation is particularly delicate when both client and supplier are active objects, since each has its own agenda. All this does not make it impossible to devise mechanisms based on the notion of active object, as evidenced by the abundant literature on the subject (to which the bibliographical notes to this chapter give many references). But this evidence also shows the complexity of the proposed solutions, of which none has gained wide acceptance, suggesting that the active object approach is not the right one. Active objects clash with inheritance Doubts about the suitability of the active object approach grow as one starts looking at how it combines with other O-O mechanisms, especially inheritance. If a class B inherits from a class A and both are active (that is to say, describe instances that must be active objects), what happens in B to the description of A’s process? In many cases you will need to add some new instructions, but without special language mechanisms this means that you will almost always have to redefine and rewrite the entire process part — not an attractive proposition. Here is an example of special language mechanism. Although the Simula 67 language does not support concurrency, it has a notion of active object: a Simula class can, besides its features, include a set of instructions, called the body of the class, so that we can talk of executing an object — meaning executing the body of its generating class. The body of a class A can include a special instruction inner, which has no effect in the class itself but, in a proper descendant B, stands for the body of B. So if the body of A reads some_initialization; inner; some_termination_actions and the body of B reads specific_B_actions then execution of that body actually means executing some_initialization; specific_B_actions; some_termination_actions Although the need for a mechanism of this kind is clear in a language supporting the notion of active object, objections immediately come to mind: the notation is misleading, since if you just read the body of B you will get a wrong view of what the execution does; it forces the parent to plan in detail for its descendants, going against basic O-O concepts (the Open-Closed principle); and it only works in a single-inheritance language. See “Sequencing and inheritance”, page 1121, as part of the discussion of Simula