From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.3 required=5.0 tests=BAYES_00,INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,555956c1cdd22308 X-Google-Attributes: gid103376,public From: Matthew Heaney Subject: Re: Help - Constructors - ASAP. Date: 1998/08/03 Message-ID: #1/1 X-Deja-AN: 377514274 Sender: matt@mheaney.ni.net References: <6p75qi$rcj@news.latnet.lv> <6pi4jq$j73$1@nnrp1.dejanews.com> <35C5C534.D773CAA2@elca-matrix.ch> NNTP-Posting-Date: Mon, 03 Aug 1998 08:54:03 PDT Newsgroups: comp.lang.ada Date: 1998-08-03T00:00:00+00:00 List-Id: Mats Weber 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.