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: nobody@REPLAY.COM (Anonymous)
Subject: Re: OOP & Packages in Ada
Date: 1998/02/02
Message-ID: <199802021537.QAA01774@basement.replay.com>#1/1
X-Deja-AN: 321379361
Content-Transfer-Encoding: 7bit
References: <6b1atp$ngp$1@Masala.CC.UH.EDU>
Content-Type: text/plain; charset=us-ascii
Organization: Replay Associates, L.L.P.
Mail-To-News-Contact: postmaster@nym.alias.net
X-001: Replay may or may not approve of the content of this posting
X-002: Report misuse of this automated service to <abuse@replay.com>
X-URL: http://www.replay.com/remailer/
Newsgroups: comp.lang.ada
Date: 1998-02-02T00:00:00+00:00
List-Id: <comp.lang.ada>


<6asp37$q8b$1@Masala.CC.UH.EDU>
<mheaney-ya023680003101981756350001@news.ni.net>

On 1 Feb 1998 08:14:49 GMT, wanker@exploited.barmy.army wrote:

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

Certainly, and that's the problem with derived types in general, and
tagged types specifically. Unless the parent is predefined or declared
in the same declarative region as the child, the result is unreadable.
There is also the problem of coupling; any package that declares a
derived type is highly coupled to the package that declares the parent
type, and as we all know, highly coupled packages are A Bad Thing.

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

Yes, we have to have knowledge of all six packages to use one, but no,
we don't need to use 6 different package names:

> 
> 
> with Objects, Organisms, Animals, Mammals, Dogs, Collies;
> for instance:
> 	Rover : Collies.Collie;
> 
> 
> Objects.Appearance (Rover);
> Organisms.Reproduction (Rover);
> ...
> Collies.Grooming (Rover);

It is the nature of derived types that the operations are defined
implicitly where the type is declared, so one can write

with Collies;
   Rover : Collies.Collie;

   Collies.Appearance (Rover);
   Collies.Reproduction (Rover);

and so on.

However, these operations (Appearance, Reproduction, and so on) do not
appear in the specification of package Collies, which, as you note, is a
nightmare for the user, who has to understand all the packages in the
hierarchy. This is what it means for packages to be highly coupled, and
is why this is A Bad Thing, and To Be Avoided.

>...

Totally An Elephant Aside: As a wanker, are you always pulling your
'ood?

Jeff Carter  PGP:1024/440FBE21
My real e-mail address: ( carter @ innocon . com )
"Hello! Smelly English K...niggets."
Monty Python & the Holy Grail

Posted with Spam Hater - see
http://www.compulink.co.uk/~net-services/spam/