Re: OOP & Packages in Ada

[wanker@exploited.barmy.army]

In article <mheaney-ya023680003101981756350001@news.ni.net>,
Matthew Heaney <mheaney@ni.net> 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
><mailto:matthew_heaney@acm.org>
>(818) 985-1271