1184 GENERICITY VERSUS INHERITANCE SB.5 B.5 COMBINING GENERICITY AND INHERITANCE It appears from the previous discussion that inheritance is the more powerful mechanism since we have not found a reasonable way to simulate it with genericity.In addition: You can express the equivalent of generic routines or packages in a language with inheritance,but this requires some duplication and complication.The verbosity is particularly hard to justify for unconstrained genericity,which requires just as much emulation effort even though it is theoretically simpler. Type checking introduces difficulties in the use of inheritance to emulate genericity Anchored declaration solves the second problem.(The reader familiar with the Chapter 17. detailed discussion of typing in an earlier chapter will,however,have noted the potential for system validity problems,which we do not need to explore further since they will disappear in the solutions finally retained below. Let us see how we can solve the first problem by introducing (reintroducing,that is) the appropriate form of genericity. Unconstrained genericity Since the major complication arises for unconstrained genericity even though it should be the simpler case,it seems adequate to provide a specific genericity mechanism for this case,avoiding the need to rely on inheritance.Consequently,we allow our classes to have unconstrained generic parameters:as we are now (at last)allowed to remember from earlier chapters,a class may be defined as class C[G,H,...].. where the parameters represent arbitrary types.To obtain a directly usable type you use a generic derivation,using types as actual generic parameters: x:C [DEVICE,RING_ELEMENT,...] This immediately applies to the queue class,which we can simply declare as indexing description:"First-in-first out queues,implemented through arrays" class OUEUE [G]creation ..The rest as before,but removing the declaration of item anchor and replacing all occurrences of type like item anchor by G... end--class OUEUE We get rid of class OUEUABLE as well as INTEGER OUEUABLE and other such descendants;to have a queue of integers,we simply use type OUEUE [INTEGER], manipulating integers directly rather than through intermediate wrapper objects. This is a remarkable simplification,suggesting that in spite of the theoretical possibility of emulating unconstrained genericity through inheritance,it is desirable in practice to introduce a generic mechanism into the object-oriented framework.1184 GENERICITY VERSUS INHERITANCE §B.5 B.5 COMBINING GENERICITY AND INHERITANCE It appears from the previous discussion that inheritance is the more powerful mechanism since we have not found a reasonable way to simulate it with genericity. In addition: • You can express the equivalent of generic routines or packages in a language with inheritance, but this requires some duplication and complication. The verbosity is particularly hard to justify for unconstrained genericity, which requires just as much emulation effort even though it is theoretically simpler. • Type checking introduces difficulties in the use of inheritance to emulate genericity. Anchored declaration solves the second problem. (The reader familiar with the detailed discussion of typing in an earlier chapter will, however, have noted the potential for system validity problems, which we do not need to explore further since they will disappear in the solutions finally retained below.) Let us see how we can solve the first problem by introducing (reintroducing, that is) the appropriate form of genericity. Unconstrained genericity Since the major complication arises for unconstrained genericity even though it should be the simpler case, it seems adequate to provide a specific genericity mechanism for this case, avoiding the need to rely on inheritance. Consequently, we allow our classes to have unconstrained generic parameters: as we are now (at last) allowed to remember from earlier chapters, a class may be defined as class C [G, H, …] … where the parameters represent arbitrary types. To obtain a directly usable type you use a generic derivation, using types as actual generic parameters: x: C [DEVICE, RING_ELEMENT, …] This immediately applies to the queue class, which we can simply declare as indexing description: "First-in-first out queues, implemented through arrays" class QUEUE [G] creation … The rest as before, but removing the declaration of item_anchor and replacing all occurrences of type like item_anchor by G … end -- class QUEUE We get rid of class QUEUABLE as well as INTEGER_QUEUABLE and other such descendants; to have a queue of integers, we simply use type QUEUE [INTEGER], manipulating integers directly rather than through intermediate wrapper objects. This is a remarkable simplification, suggesting that in spite of the theoretical possibility of emulating unconstrained genericity through inheritance, it is desirable in practice to introduce a generic mechanism into the object-oriented framework. Chapter 17