960 CONCURRENCY,DISTRIBUTION,CLIENT-SERVER AND THE INTERNET $30.3 Even with a different notation,the basic problem will remain:how to combine the process specification of a class with those of its proper descendants;how to reconcile parents'process specifications in the case of multiple inheritance. Later in this chapter we will see other problems,known as the"inheritance anomaly"and “Synchrontation for arising from the use of inheritance with synchronization constraints. concurrent O-O com- Faced with these difficulties,some of the early O-O concurrency proposals preferred putation".page 980 to stay away from inheritance altogether.Although justifiable as a temporary measure to help understand the issues by separating concerns,this exclusion ofinheritance cannot be sustained in a definitive approach to the construction of concurrent object-oriented software;this would be like cutting the arm because the finger itches.(For good measure, some of the literature adds that inheritance is a complex and messy notion anyway,as if telling the patient,after the operation,that having an arm was a bad idea in the first place.) The inference that we may draw is simpler and less extreme.The problem is not object technology per se,in particular inheritance;it is not concurrency;it is not even the combination of these ideas.What causes trouble is the notion of active object. Processes programmed As we prepare to get rid of active objects it is useful to note that we will not really be renouncing anything.An object is able to perform many operations:all the features of its generating class.By tuming it into a process,we select one of these operations as the only one that really counts.There is absolutely no benefit in doing this!Why limit ourselves to one algorithm when we can have as many as we want? Another way to express this observation is that the notion of process need not be a built-in concept in the concurrency mechanism;processes can be programmed simply as routines.Consider for example the concept of printer process cited at the beginning of this chapter.The object-oriented view tells us to focus on the object type,printer,and to treat the process as just one routine,say live,of the corresponding class: indexing description:"Printers handling one print job at a time" note:"A better version,based on a general class PROCESS, %appears below under the name PRINTER" class PRINTER I feature--Status report stop requested:BOOLEAN is do...end oldest:JOB is do ..end feature--Basic operations setup is do ..end wait for job is do ..end remove oldest is do...end print (j:JOB)is do ..end960 CONCURRENCY, DISTRIBUTION, CLIENT-SERVER AND THE INTERNET §30.3 Even with a different notation, the basic problem will remain: how to combine the process specification of a class with those of its proper descendants; how to reconcile parents’ process specifications in the case of multiple inheritance. Later in this chapter we will see other problems, known as the “inheritance anomaly” and arising from the use of inheritance with synchronization constraints. Faced with these difficulties, some of the early O-O concurrency proposals preferred to stay away from inheritance altogether. Although justifiable as a temporary measure to help understand the issues by separating concerns, this exclusion of inheritance cannot be sustained in a definitive approach to the construction of concurrent object-oriented software; this would be like cutting the arm because the finger itches. (For good measure, some of the literature adds that inheritance is a complex and messy notion anyway, as if telling the patient, after the operation, that having an arm was a bad idea in the first place.) The inference that we may draw is simpler and less extreme. The problem is not object technology per se, in particular inheritance; it is not concurrency; it is not even the combination of these ideas. What causes trouble is the notion of active object. Processes programmed As we prepare to get rid of active objects it is useful to note that we will not really be renouncing anything. An object is able to perform many operations: all the features of its generating class. By turning it into a process, we select one of these operations as the only one that really counts. There is absolutely no benefit in doing this! Why limit ourselves to one algorithm when we can have as many as we want? Another way to express this observation is that the notion of process need not be a built-in concept in the concurrency mechanism; processes can be programmed simply as routines. Consider for example the concept of printer process cited at the beginning of this chapter. The object-oriented view tells us to focus on the object type, printer, and to treat the process as just one routine, say live, of the corresponding class: indexing description: "Printers handling one print job at a time" note: “A better version, based on a general class PROCESS, % %appears below under the name PRINTER" class PRINTER_1 feature -- Status report stop_requested: BOOLEAN is do … end oldest: JOB is do … end feature -- Basic operations setup is do … end wait_for_job is do … end remove_oldest is do … end print (j: JOB) is do … end “Synchronization for concurrent O-O com￾putation”, page 980