comp.lang.ada
 help / color / mirror / Atom feed
From: Matthew Heaney <matthew_heaney@acm.org>
Subject: Re: Help - Constructors - ASAP.
Date: 1998/08/03
Date: 1998-08-03T00:00:00+00:00	[thread overview]
Message-ID: <m3sojejvav.fsf@mheaney.ni.net> (raw)
In-Reply-To: 35C5C534.D773CAA2@elca-matrix.ch

Mats Weber <Mats.Weber@elca-matrix.ch> writes:

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

You bring up a very good point.  (This is same "feature" you highlighted
in your PhD.)  One rule of thumb is that, if possible, don't declare
anything in a generic except the "main" abstract data type.  Declare
supplementary types in another package - perhaps a non-generic root
package.  In your example, type File_Type (and Count) could have gone in
package Ada.  (Of course we can't really do that for Seq_IO, for obvious
reasons.  But consider doing this for packages you write.)
 
> 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.

You can rename generic operations.

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

Indeed, this is true.  Many Ada programmers don't have a clue about how
inheritence for non-tagged types works, and certainly don't take
advantage of it.  (And those who do use it, just confuse the others).

In another post a few weeks back, I observed that if people really
wanted to simplify Ada 83, then type derivation would have been a good
candidate for removal.  I think that this is one of those things that
only Jean wanted, and he used his veto power over the rest of the DRs to
keep it in the language.





  reply	other threads:[~1998-08-03  0:00 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
1998-07-23  0:00 Help - Constructors - ASAP Maxim Senin
1998-07-26  0:00 ` Matthew Heaney
1998-07-27  0:00   ` dennison
1998-07-30  0:00     ` Robert I. Eachus
1998-07-30  0:00       ` tedennison
1998-07-31  0:00         ` Matthew Heaney
1998-07-31  0:00         ` Mats Weber
1998-07-31  0:00           ` Robert I. Eachus
1998-08-01  0:00             ` Matthew Heaney
1998-07-31  0:00           ` dennison
1998-08-01  0:00             ` Matthew Heaney
1998-08-01  0:00             ` Robert Dewar
1998-08-01  0:00               ` Matthew Heaney
1998-08-03  0:00             ` Mats Weber
1998-08-01  0:00       ` Robert Dewar
1998-08-01  0:00         ` Matthew Heaney
1998-08-03  0:00           ` Mats Weber
1998-08-03  0:00             ` Matthew Heaney [this message]
1998-08-03  0:00               ` Mats Weber
1998-08-04  0:00                 ` Matthew Heaney
1998-08-04  0:00                   ` Mats Weber
1998-08-05  0:00                     ` Matthew Heaney
1998-08-10  0:00           ` Robert I. Eachus
1998-08-03  0:00         ` tedennison
  -- strict thread matches above, loose matches on Subject: below --
1998-07-15  0:00 Maxim Senin
1998-07-16  0:00 ` Stephen Leake
replies disabled

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox