Re: Help - Constructors - ASAP.

[Mats Weber <Mats.Weber@elca-matrix.ch>]

Matthew Heaney wrote:

> 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.

This works as long as the package that implements the type exports only one
type and only primitive operations of that one type, but that is far from the
most common case, at least in my code. Take for instance Sequential_IO:

package P is

   package Implementation is new Sequential_IO(Whatever);

   type File_Type is new Implementation.File_Type;
   type File_Mode is ???; -- no clean way of doing this

end P;

Another problem, which I think is even worse, is when some operations of a
type are generics (e.g. iterators), then these will not be derived and you
will have to get them from the package that declares them.

Not to mention the fact that the rules on type derivation, primitive
operations, etc. are one of the obscure areas of the Ada language. Not to me,
I know how they work, but I have had to teach quite a few people to overtake
code that uses some (really not much) type derivation, and nobody seems to
find it natural. E.g. when you see

   X : P.T;

begin
   P.Op(X);

you expect to find a declaration for Op in P, right ?