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/05 Message-ID: #1/1 X-Deja-AN: 378007545 Sender: matt@mheaney.ni.net References: <6p75qi$rcj@news.latnet.lv> <6pi4jq$j73$1@nnrp1.dejanews.com> <35C5C534.D773CAA2@elca-matrix.ch> <35C5FCD9.2EE39FE4@elca-matrix.ch> <35C750F2.483B5A51@elca-matrix.ch> NNTP-Posting-Date: Tue, 04 Aug 1998 18:38:58 PDT Newsgroups: comp.lang.ada Date: 1998-08-05T00:00:00+00:00 List-Id: Mats Weber writes: > > Ah, but then another rule of thumb applies. Since the generic operation > > isn't primitive anyway, you just make the tagged parameters class-wide. > > Then it will work for your derived types too. > > Weren't we talking about non-tagged types ? I thought tagged types. At least some of the discussion on this thread concerned whether have the constructor return the class-wide vs specific type. > Anyway, I don't think it's a good idea to make them class-wide just > for that reason. Most often, the generic operation needs to be adapted > when inheriting, so making the tagged type parameters class-wide is > error-prone. Then we disagree. If we're talking about a hierarchy of tagged types, then there's not much difference between declaring a primitive operation of the parent type that is automatically inherited by the derived type, and manually renaming a generic operation that takes the parent class-wide type. Don't forget the example: we were deriving from the parent type by adding a null extension, to get direct visibility of the type in a different scope. The types are otherwise identical. So I don't accept your argument that making the generic operation is error-prone, because it's basically the same type. Anyway, shouldn't an operation inherited from the parent always be guaranteed to work in the derived type? If there is an inherited operation that wouldn't work in the derived type, then it's the responsibility of the derived type to override the operation so that it does work. Ditto for parent generic operations that take the parent class-wide type. If the operation will work in the derived type, then the derived type can safely rename the parent's generic operation. If the operation wouldn't work, then it is of course the responsibility of the derived type to "override" the generic parent operation by providing another. There is nothing special about the a parent operation being generic, except that (I think) you should declare the operation to take class-wide parameters, in order to simplify the life of programmer writing the derived type. (And to simplify the clients of the derived type, who will then have visibility to all the operations, including generic ones). Issues about correctness or error-proneness apply equally, whether the operation is inherited, or a renaming of a generic operation.