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.0 required=5.0 tests=BAYES_40 autolearn=ham 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: wanker@exploited.barmy.army Subject: Re: OOP & Packages in Ada Date: 1998/02/01 Message-ID: <6b1atp$ngp$1@Masala.CC.UH.EDU> X-Deja-AN: 321029307 References: <6asp37$q8b$1@Masala.CC.UH.EDU> Organization: The Exploited Barmy Army Newsgroups: comp.lang.ada Originator: punkrock@pegasus Date: 1998-02-01T00:00:00+00:00 List-Id: In article , Matthew Heaney wrote: [Snip -- Question about making methods and other attributes in parent packages appear like they are part of child packages] >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? Well in this particular case I am. [Snip -- Good analogy of a multi-volume book] >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. Well, I'm thinking along somewhat different lines. Rather than creating an "improvement" over a parent, we are simply making a new type. For example, let's use the cliched example of a biological organism: Let's assume the parent package/object has the following type: Mammal And the methods: Eat Sleep Breed Now let's say we declare a child with the following type: Dog And the method: Bark Plus, the Dog, being a type of Mammal also uses the method Eat, Sleep, and Breed. Now, in this case we want the Eat, Sleep, and Breed methods to appear to be part of the Dogs package, because otherwise the users of our package would have to know our inheritance hierarchy, and also what methods are over-ridden and what aren't. That's too much to have the user worry about, and to me seems to hurt the abstraction. I mean to the user, A dog can eat, sleep, and breed as well as bark, so it makes perfect sense to have these guys as part of the dog package. I guess it's debatable as to whether or not it's desirable to have people know that a Dog is derived from Mammal, but I don't feel it necessary. Furthermore, the situation gets really hideous if we have a pretty hefty inheritance chain like: Object (Appearance) Organism (Reproduction) Animal (Locomotion) Mammal (Fur_Thickness) Dog (Bark) Collie (Grooming) Where Object has a method Appearance, and Organism is derived from object and it has a method Reproduction, and Animal is derived from Organism, etc... Now, if we want to work on a Collie type, and wish to find out its appearance, reproduction mechanism, locomotion, fur thickness, bark, and grooming then we'd have to have a knowledge of a 6 leveled inheritance chain and call functions with 6 different namespaces qualifiers. with Objects, Organisms, Animals, Mammals, Dogs, Collies; for instance: Rover : Collies.Collie; Objects.Appearance (Rover); Organisms.Reproduction (Rover); ... Collies.Grooming (Rover); We can see that this is getting out of hand. If however the Collies package managed to make all the methods seem as a part of it, then one simply does: with Collies; Rover : Collies.Collie; Collies.Collie (Rover); Collies.Reproduction (Rover); ... Collies.Grooming (Rover); Which is a lot simpler, and would be more intuitive -- the user would not have to know or care if the methods were over-ridden or not. I've probably beat the horse to death on this one, but I wanted to make things clear about how I felt. Another person suggested with'ing with . to denote children (I haven't tried that yet), and while this would be better in that it would not force us to know the dispatching of the methods, it would still shove the inheritance hierarchy in our faces. > >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. Well, maybe I was vague, but when I said "child" I meant a child as in an inherited class, and not necessarily a child package. In this case, the child can replace (customize) the parent's functionality and supplement it, and in some cases leave it alone. But this still leaves the question of the interface open. What I'm worried about is the interface to the user. I don't want the user to see that Child draws things from Parent. I want the user to see Child as a black box and use it, and it would seem that leaving things as they are, hurts the black box abstraction. [Snip] >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. Well some of the analogies above aren't really accurate to describe what I'm thinking of. I mean giving birth to kids without appendecies isn't like inheritance, as inheritance ADDs to a system, and CUSTOMIZes it, but it does not TAKE away. I mean if the parent has an appendix as one of its features, then all inherited types will have appendices too. > >I'm sorry, I really wish it were some other way. But it isn't. That is >the nature of systems. Thank you for your detailed response. It certainly provides quite a bit of food for thought and I hope my response wasn't overly long-winded. > >-------------------------------------------------------------------- >Matthew Heaney >Software Development Consultant > >(818) 985-1271