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: 109fba,9ac62ca34a465706 X-Google-Attributes: gid109fba,public X-Google-Thread: 103376,9ac62ca34a465706 X-Google-Attributes: gid103376,public From: Gene Ouye Subject: Re: on OO differnces between Ada95 and C++ Date: 1996/02/22 Message-ID: #1/1 X-Deja-AN: 140692796 references: <4gbq7q$g08@qualcomm.com> followup-to: comp.lang.ada,comp.lang.c++ content-type: TEXT/PLAIN; charset=US-ASCII organization: Rational Software Corporation mime-version: 1.0 newsgroups: comp.lang.c++,comp.lang.ada Date: 1996-02-22T00:00:00+00:00 List-Id: John English wrote: [...] > If the spec of Saving_Account has "with Account" at the beginning, > "with Saving_Account" will imply "with Account". This is not true. In order to compile and link the entire application, if you have a module "X" that with's Saving_Account, then X is indirectly dependent on Account (ie, you can't link X without having Account already compiled), but there is no implicit "with" that is included. The with clause means you have visibility to declarations in referenced unit, in the above example, X, by withing Saving_Account has visibility to Saving_Account declaration, but NOT to Account declarations. However, Saving_Account, because it with'ed Account, does have visibility to Account declarations. > Or use child packages: make Saving_Account a child of Account (e.g. > Account.Saving) so that it is effectively an extension of Account. This is true (as many others have demonstrated in this thread). [...] > You can always put "subtype Money_Type is Account.Money_Type" in > Saving_Account to make it directly usable from Saving_Account... Yes, you can do this, but it probably won't do what I think you were intending. You will have a Saving_Account.Money_Type that is visible, but the values of the subtype may not be visible (if it's numeric, then the numeric literals are directly convertible, but if it's, say, an enumeration type, the enumeration literals aren't made directly visible by a subtype declaration). In any case, numeric type or no, the operations aren't brought along with a subtype declaration. So you could assign numeric literals to objects of the subtype Saving_Account.Money_Type, but you couldn't invoke any operations on objects of that type unless you somehow got visibility to them in Account (where they are declared). Many have posted ways for this to be done, so there's no need for me to get into them here... If you're interested in religious language flame wars, you could say that this is a case where Ada doesn't to what is expected. But if you understand what the subtype declaration really does, then this behavior really should be expected. In other words, whether you're doing C++ or Ada, you can't expect the language subtleties to be "expected" unless you get some education. Gene Ouye