Re: Help - Constructors - ASAP.

[Matthew Heaney <matthew_heaney@acm.org>]

dewar@merv.cs.nyu.edu (Robert Dewar) writes:

> Well, the cases where safe inheritance would be feasible are limited to
> extensions of the type with no additional fields, not very useful!

This is the Ada 95 counterpart to the "Transitivity of Visibility"
technique described in the Ada 83 Rationale.

This is helpful when you have a type that comes into existence because
of a nested instantation.  For example:

generic
...
package GQ is 

   type T is tagged ...;
...
end GQ;

with GQ;
pragma Elaborate_All (GQ);

package P is
...
   package Q is new GQ (...);

   type T is new Q.T with null record;
...
end P;

What you do NOT want to happen is to for a client to have to refer to
P.Q.T.  The client shouldn't have to care that T was brought into
existence because of an instantiation; it's really an implementation
detail.  By using transitivity of visibility, the client can just refer
to P.T, in effect "hiding" the fact that T comes from Q.

You can do this with non-tagged types too.  One common mistake I see
programmers make is to do this:

package P is

   package Bounded_Strings_20 is
     new Ada.Strings.Bounded.Generic_Bounded_Length (20);
...
end P;

Now every client in the universe has to refer to the string type as
P.Bounded_Strings_20.Bounded_String.  Why should a client care?  

Use the transitivity of visibility technique to bring the string type
directly in the scope of P:

package P is

   package Bounded_Strings_20 is
     new Ada.Strings.Bounded.Generic_Bounded_Length (20);

   type Bounded_String is
     new Bounded_Strings_20.Bounded_String;
...
end P;

Now a client can just refer to P.Bounded_String.

Ah, simple.  Life is good.

Matt