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=-0.8 required=5.0 tests=BAYES_00,INVALID_DATE autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,a8985ede8fe3d111 X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 1994-10-23 12:14:45 PST Newsgroups: comp.lang.ada Path: bga.com!news.sprintlink.net!howland.reston.ans.net!EU.net!uunet!noc.near.net!ray.com!news.ray.com!news.ed.ray.com!swlvx2!jgv From: jgv@swl.msd.ray.com (John Volan) Subject: Re: Child packages Date: Thu, 20 Oct 1994 13:52:27 GMT Message-ID: <1994Oct20.135227.28827@swlvx2.msd.ray.com> References: <384dh5$efd@network.ucsd.edu> Sender: news@swlvx2.msd.ray.com (NEWS USER) Organization: Raytheon Company, Tewksbury, MA Date: 1994-10-20T13:52:27+00:00 List-Id: mbk@inls1.ucsd.edu (Matt Kennel) writes: >Robert I. Eachus (eachus@spectre.mitre.org) wrote: >: In article <3816h5$n3g@schonberg.cs.nyu.edu> dewar@cs.nyu.edu (Robert Dewar) writes: >: > One thing that should be emphasized about child packages (since some of >: > the posts of this thread have not been clear on this point) is that >: > child packages in no way change their parents. If you have a parent A, >: > and a child A.B, then if A.B does horrible things to the abstractions >: > in A, it still does not affect anyone who with's only package A. It is >: > only if package A.B is with'ed that the effects of the child are >: > noticable. >: Very misleading. If a PROGRAM doesn't include any withs of a >: child, the child is not part of that program and can't harm it. But a >: child unit can--even during elaboration--change hidden state in the >: parent's private part. >Question: do you mean objects declared to be type of the parent >may be harmed due to the fact that there are subclasses of >this parent? This sounds dumb. This isn't true, is it? >Of course, if you create a child class which takes some implementation >from a parent sure you might screw up the implementation taken from >the parent, but this should only affect you if you use >objects of the child class, right? Matt, you are confusing child units and package hierarchies with inheritance and class hierarchies. They are not the same thing. Child units and package hierarchies are a pure "modularity" concept, one that that is new to Ada9X. The hierarchical library mechanism deals with issues of scope, visibility, encapsulation, information hiding, and separate compilation. On the other hand, class hierarchies and inheritance, well-known in so many object-oriented languages, are treated as a "typing" concept in Ada9X, and are implemented in terms of tagged types, type derivation, and type extension. Your background as an Eiffel programmer is showing. Eiffel is a language designed to adhere to the principle of 1 MODULE = 1 TYPE. This principle is the "One and Only True Way" of today's object-oriented orthodoxy. But the design of Ada (83 and 9X) makes no attempt to rigidly follow that orthodoxy. Mind you, it doesn't *preclude* the idea of 1 MODULE = 1 TYPE. Indeed, as I've been trying to show on another thread, it's possible to adhere to a style of 1 PACKAGE = 1 CLASS even under the most strenuous conditions without resorting to grotesque workarounds. However, Ada9X doesn't *require* you to follow this style as the "One and Only True Way". In fact, Ada9X's hierarchical library allows programmers to deal with modularity issues at levels of granularity *beyond* the class-level (e.g., "subsystems") -- *without* having to look beyond the programming language for support. At the same time, it supports levels of granulatiry *smaller* than the class-level (different aspects of a class's functionality might be dealt with in different child units -- well, as long as that functionality doesn't have to be "primitive"). If you haven't already done so, it might help you to download and read the Ada 9X Rationale, which is available by anonymous FTP from the AJPO host, in ftp://ajpo.sei.cmu.edu/public/ada9x/rm9x >-- >-Matt Kennel mbk@inls1.ucsd.edu >-Institute for Nonlinear Science, University of California, San Diego >-*** AD: Archive for nonlinear dynamics papers & programs: FTP to >-*** lyapunov.ucsd.edu, username "anonymous". -- John Volan -------------------------------------------------------------------------------- -- Me : Person := (Name => "John Volan", -- Company => "Raytheon Missile Systems Division", -- E_Mail_Address => "jgv@swl.msd.ray.com", -- Affiliation => "Enthusiastic member of Team Ada!", -- Humorous_Disclaimer => "These opinions are undefined " & -- "by my employer and therefore " & -- "any use of them would be " & -- "totally erroneous."); --------------------------------------------------------------------------------