Re: tagged types extensions - language design question

["Matthew Heaney" <matthew_heaney@acm.org>]

In article <s94522bcq0s54@corp.supernews.com> , "Vladimir Olensky" 
<vladimir_olensky@yahoo.com> wrote:

>>It's hard to make hard and fast rules here, but in general, you should
>>use a package hierarchy to declare a type hierarchy.  (This would be
>>required in other OOP languages as well.)
>
>
> This is what I am doing in reality but additional intermediate packages
> for derived types with public attributes break naming scheme in this chain.

The intermediate type (the one with the public attributes) need not
break the naming scheme.

You can declare the intermediate type in its own package, and then types
that derive from that one simply 'with' the package, instead of becoming
a child.

Here's some code:

package P is

   type T is tagged private;

private

   type T is tagged record
      I : Integer;
   end record;

end P;


package P.C is

   type NT is abstract new T with record
      F : Float;
   end record;

end P.C;


with P.C;
package P.C1 is

   type NT1 is new P.C.NT with private;

private

   type NT1 is new P.C.NT with record
      B : Boolean;
   end record;

end P.C1;


with P.C;
package P.C2 is

   type NT2 is new P.C.NT with private;

private

   type NT2 is new P.C.NT with record
     Another_Float : Long_Float;
   end record;

end P.C2;


with P.C1;
with P.C2;
procedure Test_Public is

   O1 : P.C1.NT1;
   O2 : P.C2.NT2;

begin

   O1.F := 2.5;
   O2.F := 3.4;

end Test_Public;


This is an example of a type hierarchy *not* following the package
hierarchy.  Types NT1 and NT2 both derive from intermediate type P.C.NT,
but they are declared in child packages of P, not P.C.

As they say, the exception proves the rule.

Does this meet your needs?


--
Philosophy may be ignored but not escaped; and those who most ignore
least escape.

David Hawkins