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: eachus@spectre.mitre.org (Robert I. Eachus) Subject: Re: Help - Constructors - ASAP. Date: 1998/08/10 Message-ID: #1/1 X-Deja-AN: 379831015 References: <6p75qi$rcj@news.latnet.lv> <6pi4jq$j73$1@nnrp1.dejanews.com> Organization: The Mitre Corp., Bedford, MA. Newsgroups: comp.lang.ada Date: 1998-08-10T00:00:00+00:00 List-Id: In article Matthew Heaney writes: > This is helpful when you have a type that comes into existence because > of a nested instantation. For example... > with GQ; > pragma Elaborate_All (GQ); > package P is > ... > package Q is new GQ (...); > type T is new Q.T with null record; -- and this is the case where you want to inherit the construtor: function Create_T(...) return T; -- of course, if you forget to do this, the compiler will be -- sure to remind you. ;-) > ... > end P; -- and also in the package body: function Create_T(...) return T is begin return Q.T(Q.Create_T(...)); end Create_T; It is a bit of a pain when you need to do it right, but as you can see, it amounts to a line in the spec and two in the body. > 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. Exactly, the user of the abstraction should never need to pay attention to the man behind the curtin. -- Robert I. Eachus with Standard_Disclaimer; use Standard_Disclaimer; function Message (Text: in Clever_Ideas) return Better_Ideas is...