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,98f446539174ef31 X-Google-Attributes: gid103376,public From: mheaney@ni.net (Matthew Heaney) Subject: Re: OOP & Packages in Ada Date: 1998/01/31 Message-ID: #1/1 X-Deja-AN: 320967179 Content-Transfer-Encoding: 8bit References: <6asp37$q8b$1@Masala.CC.UH.EDU> Content-Type: text/plain; charset=ISO-8859-1 Organization: Estormza Software Mime-Version: 1.0 Newsgroups: comp.lang.ada Date: 1998-01-31T00:00:00+00:00 List-Id: In article <6asp37$q8b$1@Masala.CC.UH.EDU>, wanker@exploited.barmy.army wrote: >I've got a question for you. Assuming we have two packages, >say Parents and Children, and Children contains a type, >Child, that is inherited from a type in Parents (Parents.Parent), >is there a way to easily make all the methods of Parents.Parent >available to Child, so that just with'ing the Children package will >make these methods available? Wrapper functions/procedures >or renaming might do this, but is there an easier way? I think you need to rethink the question. The answer is, no, you cannot make all the "resources" in package Parent directly visible from package Child. But are you sure you want to? Consider an analogy. Suppose you wrote a technical book, with all kinds of great infomation. You use the book for awhile, and later realize there's more cool stuff you'd like to document. You'd like to have one book that has all the old stuff and the new stuff, but it's too late. Everyone is already using the original book, and references to information in the book refer to that book directly. So what do you do? You write another book, and call it Volume II. For someone to get all the information, instead of checking out one book, you check out two books. You must understand the principles of evolution of complex systems. In order to reach point B, you have to have traversed throught point A. Plus, you can't throw away all the infrastructure already in place when you're in B, even if you're smarter now and know there's a better way. What remains from before is called a "vestigial" characteristic, just as the human appendix is a "vestigial organ" of what we were before. The resources exported by a child package are intended to *supplement* the resources of the parent package, not replace them. That is why I recommend you reask the question. You must consider the packages in their totality, as a group. In answer to Mats Weber: No, that the operations were classwide was *not* a mistake. It's analogous to a package I know you're intimately familiar with: package Text_IO, which you discussed in your thesis. Even if File_Type (which should have been named Text_File, Brian :-) were tagged, and you derived from it in a child package, a client of the child still wouldn't get directly visibility to types Count and Positive_Count - he has to go to the parent to get them. Ditto for the exceptions raised by the primitive operations of File_Type'Class. So inheritence is not the answer. It would be really swell if woman could give birth to babies without appendices. It would be swell if we could remember more than seven things at one time (read Miller's famous paper). It would be just jolly if no one were near-sighted. Or could grow limbs back. But these are features of the system, and we're stuck with them, like it or not. In Biomorph Land, one can only take a small conservative jump, so wherever you are, you are the product of what you have been (read Dawkins' The Blind Watchmaker, or D'Arcy Thompson's On Growth and Form, or anything by Stephen Jay Gould). Take a different path, and you get a different system. I'm sorry, I really wish it were some other way. But it isn't. That is the nature of systems. -------------------------------------------------------------------- Matthew Heaney Software Development Consultant (818) 985-1271