Subject: | |
From: | |
Reply To: | |
Date: | Tue, 8 Dec 1998 12:30:57 -0800 |
Content-Type: | TEXT/PLAIN |
Parts/Attachments: |
|
|
On Mon, 7 Dec 1998, Matthew Heaney wrote:
> If you import that type as a private, you'll have to import literals
> too:
>
> generic
> type T is private;
> One : in T;
> with function "+" (L, R : T) return T is <>;
Actually, in the design I suggested there is no need for literals.
Instead, one would include generic formal subprograms that return
a set of values necessary to for instantiation with any private
type.
For example,
generic
type Item is private;
with function Zero_Equivalent return Item;
with function Tic_First return Item;
with function Increment return Item;
with function Tic_Last return Item;
-- Now the arithmetic and relational operators
-- Use default notation for all operators
with function "+" (L, R : Item) return Item is <>;
-- etc.
package Generic_Math_Ops is end Generic_Math_Ops;
With this model, one can instatiate with a record type such as a fraction,
an access type, or any other type for which assignment is permitted. This
can also be used as a package for instantiating under the rules of
generic formal package parameters. For example,
with Generic_Math_Ops;
generic
with package Math_Ops is new Generic_Math_Ops ... ;
package Statistical_Analysis is
-- any set of services here
end Statistical_Analysis;
If you do instantiate with a type for which there is a set of predefined
operators, the use of the default reduces the number of actual arguments.
I prefer to define generic formal functions rather than constants to make
the design more flexible. In fact, I have eschewed the use of deferred
constants in favor of functions for ordinary packages. Deferred constants
are not as maintainable as functions returning constant values.
Richard Riehle
[log in to unmask]
http://www.adaworks.com
|
|
|