1084 O-O PROGRAMMING AND ADA $33.3 You still need the full form,however,for any entity whose name conflicts with the name of another accessible to the client package (that is to say,declared in that package itself or in another supplier listed in a use directive). Some of the Ada literature advises programmers to stay away from the use directive altogether on the grounds that it hampers clarity:an unqualified reference such as empry(s) does not immediately tell the reader what supplier empty comes from(REAL STACK.S in the example).The equivalent in the object-oriented approach,s.empty,unambiguously indicates the supplier through the type of s. A similar problem does arise in the O-O world because of inheritance:when you see a “FLATTENING THE name in a class,it may refer to a feature declared in any ancestor.But we saw a technique STRUCTURE”,page that solves this problem at least in part:the notion of flat form. 541. Implementation The body of the REAL STACKS package might be declared along the following lines. Only one routine is shown in full. package body REAL STACKS is procedure put (x:in FLOAT:s:in out REAL STACK)is begin if s.count =s.capacity then raise Overflow end if; S.coumt :S.count +1: s.implementation (count):=x; end put; procedure remove (s:in out STACK)is ..Implementation of remove... end remove; function item (s:STACK)return X is ..Implementation of item .. end item; function empty (s:STACK)return BOOLEAN is ..Implementation of empty... end empty, end REAL STACKS; Two properties apparent in this example will be developed in more detail below:the use of exceptions to handle a run-time error by raising a special condition and treating it separately;and the need for the body to repeat most of the interface information(routine headers)that already appeared in the interface. Genericity The package as given is too specific;it should be made applicable to any type,not just FLO4T.To turn it into a generic package,use the following syntax:1084 O-O PROGRAMMING AND ADA §33.3 You still need the full form, however, for any entity whose name conflicts with the name of another accessible to the client package (that is to say, declared in that package itself or in another supplier listed in a use directive). Some of the Ada literature advises programmers to stay away from the use directive altogether on the grounds that it hampers clarity: an unqualified reference such as empty (s) does not immediately tell the reader what supplier empty comes from (REAL_STACKS in the example). The equivalent in the object-oriented approach, s● empty, unambiguously indicates the supplier through the type of s. A similar problem does arise in the O-O world because of inheritance: when you see a name in a class, it may refer to a feature declared in any ancestor. But we saw a technique that solves this problem at least in part: the notion of flat form. Implementation The body of the REAL_STACKS package might be declared along the following lines. Only one routine is shown in full. package body REAL_STACKS is procedure put (x: in FLOAT; s: in out REAL_STACK) is begin if s ● count = s ● capacity then raise Overflow end if; s ● count := s ● count + 1; s ● implementation (count) := x; end put; procedure remove (s: in out STACK) is … Implementation of remove … end remove; function item (s: STACK) return X is … Implementation of item … end item; function empty (s: STACK) return BOOLEAN is … Implementation of empty … end empty; end REAL_STACKS; Two properties apparent in this example will be developed in more detail below: the use of exceptions to handle a run-time error by raising a special condition and treating it separately; and the need for the body to repeat most of the interface information (routine headers) that already appeared in the interface. Genericity The package as given is too specific; it should be made applicable to any type, not just FLOAT. To turn it into a generic package, use the following syntax: “FLATTENING THE STRUCTURE”, page 541