SB.4 EMULATING GENERICITY WITH INHERITANCE 1179 Constrained genericity:packages The previous discussion transposes to packages.To emulate the matrix abstraction which Ada implemented through the M4TR/CES package,we can use a class: class MATRIX feature anchor:RING ELEMENT is do end implementation:ARRAY2 [like anchor] item (i,j:INTEGER):like anchor is --Value of(i,j)entry do Result implementation.item (i,j)end put (i,j:INTEGER;v:like anchor)is --Assign value y to entry (i,j) do implementation.put (i,j,v)end infix "+"(other:like Current):like Current is --Matrix sum of current matrix and other local i,j:INTEGER do !Result.make (... from i:=...until ..loop fromj:=...until ..loop Result.put ((item (i,j)+other.item (i,j)),i,j) j=+1 end i:=i+1 end end infix "*"(other:like Current):like Current is --Matrix product of current matrix by other local ..do...end end--class MATRIX The type of the argument to put and of the result of item raises an interesting problem:it should be RING ELEMENT,but redefined properly in descendant classes. Anchored declaration is the solution;but here for the first time no attribute of the class seems to be available to serve as anchor.This should not stop us,however:we declare an artificial anchor,called anchor.Its only purpose is to be redefined to the proper descendant types of RING ELEMENT in future descendants of MATRLY (that is to say,to BOOLEAN RING in BOOLEAN MATRIX etc.),so that all associated entities will follow. To avoid any space penalty in instances,anchor is declared as a function rather than an attribute.This technique of artificial anchors is useful to preserve type consistency when, as here,there is no "natural"anchor among the attributes of the class.§B.4 EMULATING GENERICITY WITH INHERITANCE 1179 Constrained genericity: packages The previous discussion transposes to packages. To emulate the matrix abstraction which Ada implemented through the MATRICES package, we can use a class: class MATRIX feature anchor: RING_ELEMENT is do end implementation: ARRAY2 [like anchor] item (i, j: INTEGER): like anchor is -- Value of (i, j) entry do Result := implementation ● item (i, j) end put (i, j: INTEGER; v: like anchor) is -- Assign value v to entry (i, j). do implementation ● put (i, j, v) end infix "+" (other: like Current): like Current is -- Matrix sum of current matrix and other local i, j: INTEGER do !! Result ● make (…) from i := … until … loop from j := … until … loop Result ● put ((item (i, j) + other ● item (i, j)), i, j) j := j + 1 end i := i + 1 end end infix "∗" (other: like Current): like Current is -- Matrix product of current matrix by other local … do … end end -- class MATRIX The type of the argument to put and of the result of item raises an interesting problem: it should be RING_ELEMENT, but redefined properly in descendant classes. Anchored declaration is the solution; but here for the first time no attribute of the class seems to be available to serve as anchor. This should not stop us, however: we declare an artificial anchor, called anchor. Its only purpose is to be redefined to the proper descendant types of RING_ELEMENT in future descendants of MATRIX (that is to say, to BOOLEAN_RING in BOOLEAN_MATRIX etc.), so that all associated entities will follow. To avoid any space penalty in instances, anchor is declared as a function rather than an attribute. This technique of artificial anchors is useful to preserve type consistency when, as here, there is no “natural” anchor among the attributes of the class