1168 GENERICITY VERSUS INHERITANCE $B.I B.1 GENERICITY We begin our review by appraising the merits of genericity as it exists in a number of languages,object-oriented or not.Let us rely for convenience on the notations- semicolons and all-of the best known non-O-O generic language,Ada(meaning by default,as elsewhere in this book,Ada 83).So for the rest of this section we forget about O-O languages and techniques. Only the most important form of Ada genericity will be considered:type parameterization,that is to say the ability to parameterize a software element(in Ada,a package or routine)by one or more types.Generic parameters have other,less momentous uses in Ada,such as parameterized dimensions for arrays.We may distinguish between unconstrained genericity,imposing no specific requirement on generic parameters,and constrained genericity,whereby a certain structure is required. Unconstrained genericity Unconstrained genericity removes some of the rigidity of static typing.A trivial example is a routine (in a language with Ada-like syntax but without explicit type declarations)to swap the values of two variables: procedure swap (x,y)is This extract and the local next few are in Ada or Ada-like syntax. begin t:=x;x:=yy:=t end swap; This form does not specify the types of the elements to be swapped and of the local variable 1.This is too much freedom,since a call swap (a,b),where a is an integer and b a character string,will not be prohibited even though it is probably an error. To address this issue,statically typed languages such as Pascal and Ada require developers to declare explicitly the types of all variables and formal arguments,and enforce a statically checkable type compatibility constraint between actual and formal arguments in calls and between source and target in assignments.The procedure to exchange the values of two variables of type G becomes: procedure G_swap (x,y:in out G)is t:G; begin t:=x;x:=yy:=t; end swap, Demanding that G be specified as a single type averts type incompatibility errors,but in the constant haggling between safety and flexibility we have now erred too far away from flexibility:to correct the lack of safety of the first solution,we have made the solution inflexible.We will need a new procedure for every type of elements to be exchanged,for example INTEGER swap,STRING swap and so on.Such multiple declarations lengthen and obscure programs.The example chosen is particularly bad since all the declarations will be identical except for the two occurrences of G.1168 GENERICITY VERSUS INHERITANCE §B.1 B.1 GENERICITY We begin our review by appraising the merits of genericity as it exists in a number of languages, object-oriented or not. Let us rely for convenience on the notations — semicolons and all — of the best known non-O-O generic language, Ada (meaning by default, as elsewhere in this book, Ada 83). So for the rest of this section we forget about O-O languages and techniques. Only the most important form of Ada genericity will be considered: type parameterization, that is to say the ability to parameterize a software element (in Ada, a package or routine) by one or more types. Generic parameters have other, less momentous uses in Ada, such as parameterized dimensions for arrays. We may distinguish between unconstrained genericity, imposing no specific requirement on generic parameters, and constrained genericity, whereby a certain structure is required. Unconstrained genericity Unconstrained genericity removes some of the rigidity of static typing. A trivial example is a routine (in a language with Ada-like syntax but without explicit type declarations) to swap the values of two variables: procedure swap (x, y) is local t; begin t := x; x := y; y := t; end swap; This form does not specify the types of the elements to be swapped and of the local variable t. This is too much freedom, since a call swap (a, b), where a is an integer and b a character string, will not be prohibited even though it is probably an error. To address this issue, statically typed languages such as Pascal and Ada require developers to declare explicitly the types of all variables and formal arguments, and enforce a statically checkable type compatibility constraint between actual and formal arguments in calls and between source and target in assignments.The procedure to exchange the values of two variables of type G becomes: procedure G_swap (x, y: in out G) is t: G; begin t := x; x := y; y := t; end swap; Demanding that G be specified as a single type averts type incompatibility errors, but in the constant haggling between safety and flexibility we have now erred too far away from flexibility: to correct the lack of safety of the first solution, we have made the solution inflexible. We will need a new procedure for every type of elements to be exchanged, for example INTEGER_swap, STRING_swap and so on. Such multiple declarations lengthen and obscure programs. The example chosen is particularly bad since all the declarations will be identical except for the two occurrences of G. This extract and the next few are in Ada or Ada-like syntax