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: Jon S Anthony <jsa@synquiry.com>
Subject: Re: OOP & Packages in Ada
Date: 1998/02/02
Message-ID: <uf90rt381v.fsf@synquiry.com>#1/1
X-Deja-AN: 321497480
References: <6asp37$q8b$1@Masala.CC.UH.EDU>
 <mheaney-ya023680003101981756350001@news.ni.net>
 <6b1atp$ngp$1@Masala.CC.UH.EDU>
Distribution: world
Organization: PSINet
Newsgroups: comp.lang.ada
Date: 1998-02-02T00:00:00+00:00
List-Id: <comp.lang.ada>


wanker@exploited.barmy.army writes:

> 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.

Yes, but that is a well known problem with class based OO stuff.


> 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.

They _are_ part of the dog package.  It's just that they are
_implicitly_ declared.  Of course that implies from a documentation
point of view this doesn't help you much (at all...)


> 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

Well that's easy enough to fix if you want.  You can make the Dog type
private and then derive if in the private part of the package.  You
then define all the methods you want on Dog in the public part and
indicate they are implemented as the parent Mammal versions in the
private part or the body.  This gives you what you want, but at a cost
of not being able to "conveniently" extend the type later.  Note: all
the polymorphic stuff will still work just fine, you just won't see it
in the clients.


> 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

Yes, but that's just standard class based OO.


> and call
> functions with 6 different namespaces qualifiers.

But, no, you can simply use the appropriate most specific one you
want.


> 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:

It does.  Read 3.4 carefully.  In particular (17).  For example,

package Animals is

    type Animal is tagged null record;

function Appearance (X : Animal ) return String;

end Animals;


package Animals.Organisms is

    type Organism is new Animal with null record;

function Locomotion (X : Organism) return String;
function Reproduction (X : Organism) return String;

end Animals.Organisms;


package Animals.Organisms.Mammals is

    type Mammal is new Organism with null record;

function Fur_Thickness (X: Mammal) return String;

end Animals.Organisms.Mammals;


package Animals.Organisms.Mammals.Dogs is

    type Dog is new Mammal with null record;

function Bark (X : Dog) return String;

end Animals.Organisms.Mammals.Dogs;


package Animals.Organisms.Mammals.Dogs.Collies is

    type Collie is new Dog with null record;

function Grooming (X: Collie) return String;

end Animals.Organisms.Mammals.Dogs.Collies;


with Animals.Organisms.Mammals.Dogs.Collies;
use Animals.Organisms.Mammals.Dogs.Collies;

with Ada.Text_Io;  use Ada.Text_Io;

procedure Test is

    Rover : Collie;

begin
    Put_Line(
        "Rover : " &
        Appearance(Rover) &
        Reproduction(Rover) &
        Locomotion(Rover) &
        Fur_Thickness(Rover) &
        Bark(Rover) &
        Grooming(Rover));
end Test;

$ gnat test.adb
$ ## no problemo...

> 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.

Well, then, you should be happy.


/Jon

-- 
Jon Anthony
Synquiry Technologies, Ltd., Belmont, MA 02178, 617.484.3383
"Nightmares - Ha!  The way my life's been going lately,
 Who'd notice?"  -- Londo Mollari