SB.4 EMULATING GENERICITY WITH INHERITANCE 1181 class BOOLEAN MATRIX inherit MATRIX redefine anchor end feature anchor:BOOLEAN RING ELEMENT end -class BOOLEAN MATRIX See the box on page This construction achieves the effect of constrained genericity using inheritance, 1178. confirming for packages the emulation result initially illustrated for routines. Unconstrained genericity The mechanism for simulating unconstrained genericity is the same;we can simply treat this case as a special form of constrained genericity,with an empty set of constraints.As above,formal type parameters will be interpreted as abstract data types,but here with no relevant operations.The technique works,but becomes rather heavy to apply since the dummy types do not correspond to any obviously relevant data abstraction. Let us apply the previous technique to both our unconstrained examples,swap and queue,beginning with the latter.We need a class,say OUEUABLE,describing objects that may be added to and retrieved from a queue.Since this is true of any object,the class has no other property than its name: class OUEUABLE end We may now declare a class QUEUE,whose operations apply to OUEUABLE objects.(Remember that this class is not offered as a paragon of good O-O design:we are still voluntarily playing with an impoverished version of the O-O notation,devoid of genericity.)Routine postconditions have been left out for brevity.Although in principle function item could serve as an anchor,its body will not change in descendants,so it is better to use an artificial anchor item anchor to avoid having to redefine item. indexing description:"First-in-first out queues,implemented through arrays" class OUEUE creation make feature--Initialization make (m:INTEGER)is --Create queue with space for m items. require m>=0 do !implementation.make (1,m),capacity m first :1;next:=1 end§B.4 EMULATING GENERICITY WITH INHERITANCE 1181 class BOOLEAN_MATRIX inherit MATRIX redefine anchor end feature anchor: BOOLEAN_RING_ELEMENT end -- class BOOLEAN_MATRIX This construction achieves the effect of constrained genericity using inheritance, confirming for packages the emulation result initially illustrated for routines. Unconstrained genericity The mechanism for simulating unconstrained genericity is the same; we can simply treat this case as a special form of constrained genericity, with an empty set of constraints. As above, formal type parameters will be interpreted as abstract data types, but here with no relevant operations. The technique works, but becomes rather heavy to apply since the dummy types do not correspond to any obviously relevant data abstraction. Let us apply the previous technique to both our unconstrained examples, swap and queue, beginning with the latter. We need a class, say QUEUABLE, describing objects that may be added to and retrieved from a queue. Since this is true of any object, the class has no other property than its name: class QUEUABLE end We may now declare a class QUEUE, whose operations apply to QUEUABLE objects. (Remember that this class is not offered as a paragon of good O-O design: we are still voluntarily playing with an impoverished version of the O-O notation, devoid of genericity.) Routine postconditions have been left out for brevity. Although in principle function item could serve as an anchor, its body will not change in descendants, so it is better to use an artificial anchor item_anchor to avoid having to redefine item. indexing description: "First-in-first out queues, implemented through arrays" class QUEUE creation make feature -- Initialization make (m: INTEGER) is -- Create queue with space for m items. require m >= 0 do !! implementation ● make (1, m); capacity := m first := 1; next := 1 end See the box on page 1178