OOP & Packages in Ada

OOP & Packages in Ada

[wanker]

Hey all,

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?

Here is an example of what I'm talking about:

[Possibly incorrect Ada source follows, but you get the picture]

In package Parents, there exists the following declarations:

type Parent is tagged 
    record
	...
    end record;

function  X (P : in Parent'Class) returns Integer;
procedure Y (P : in out Parent'Class);
procedure Z (P : out Parent'Class);


And in package Children there exist the following:

type Child is new Parents.Parent with
   record
	...
   end record;


Now let's say we have a main program that withs both of
these packages, so we have something like:

procedure Main is
    P : Parents.Parent;
    C : Children.Child;
begin
   Parents.X (P);
   Parents.X (C);
end Main;

Now, one problem with this code, is that the user seems to have
to know that the method X for C is located in an entirely
different package.  Is there a way to have the package
Children inherit the methods of its parents and make them
visible so they act like it's own?

In other words, is there a way that we can easily make it
so that we can say:
	Children.X (C);

Instead of:
	Parents.X (C);

Without having to do stuff like renaming every function inside
the child?

Thanks

Re: OOP & Packages in Ada

[Mats Weber]

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

Yes, there is. Do yourself a favor: go to <http://www.adahome.com>, look at
the books section, buy one, spend a day reading it, or look at one of the
tutorials (but don't even try learning from the Ada 95 RM). That way you will
learn how Ada 95's tagged types work and how to use them right. OOP in Ada 95
is a little different form what you have in other OO languages, and it's best
to learn before trying or you (or someone else) will have to maintain code
that is not written right.

> type Parent is tagged
>     record
>         ...
>     end record;
> 
> function  X (P : in Parent'Class) returns Integer;
> procedure Y (P : in out Parent'Class);
> procedure Z (P : out Parent'Class);

These are class-wide operations. It's probably not what you want.

Sorry for being so paternalistic :-)

Re: OOP & Packages in Ada

[Nick Roberts]

I would agree with Mats' advice, but, for the record, I think the answer to
your question is more or less as follows.

First, let's assume that there is a function X defined for type Parent in
package Parents as:

   function X (P: Parent) return Result_Type;

and another function X defined for type Child in package Children as:

   function X (C: Child) return Result_Type;

Programmers would then put something like

   with Parents.Children;

in front of their units which were going to use the type Child.  This
'with' clause makes the entities specified by Parents available as well as
those specified by Children.  So the function X which takes Parent as its
parameter would be available as well as the X which takes the type Child as
its parameter (but neither are directly visible, note).

Now, the programmer could either put

   use Parents, Children;

and then declare

   P: Parent;
   C: Child;

and then put

   Y := X(P);
   Z := X(C);

where the two calls to X will be resolved by overloading; or the programmer
could simply declare

   P: Parents.Parent;
   C: Children.Child;

and then put

   Y := Parents.X(P);
   Z := Children.X(C);

where the two calls to X are differentiated explicitly.

Perhaps the point is that the programmer _should_ have to make explicit
reference to the package Parents when using the type Parent, because that's
where it is declared.  If the type Child provides all the same
functionality of Parent (with, perhaps, more added), then the programmer is
using type Child all the time: type Parent remains unused -- it just
provides a 'baseline' from which other types are to be derived. 

-- 

== Nick Roberts ================================================
== Croydon, UK                       ===========================
==                                              ================
== Proprietor, ThoughtWing Software                   ==========
== Independent Software Development Consultant            ======
== Nick.Roberts@dial.pipex.com                              ====
== Voicemail & Fax +44 181-405 1124                          ===
==                                                            ==
==           I live not in myself, but I become               ==
===          Portion of that around me; and to me             ==
====         High mountains are a feeling, but the hum        ==
=======      Of human cities torture.
===========                             -- Byron [Childe Harold]

Re: OOP & Packages in Ada

[Matthew Heaney]

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
<mailto:matthew_heaney@acm.org>
(818) 985-1271

Re: OOP & Packages in Ada

[wanker]

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

Re: OOP & Packages in Ada

[Tom Moran]

Is this what you want:
package parent is
  type mammal is tagged null record;
  procedure eat(x : in out mammal);
end parent;

with ada.text_io;
package body parent is
  procedure eat(x : in out mammal) is
  begin ada.text_io.put_line("eat");end eat;
end parent;

with parent;
package child is
  type dog is new parent.mammal with null record;
  procedure bark(x : in out dog);
end child;

with ada.text_io;
package body child is
  procedure bark(x : in out dog) is
  begin ada.text_io.put_line("bark");end bark;
end child;

with child;
procedure user is
  rover : child.dog;
begin
  child.bark(rover);
  child.eat(rover);
end user;
    Note that primitive operations are inherited by child and appear
to user as if child declared them.  This isn't so for other things -
other types, constants, variables, etc.  For instance, if we add
  epitome : mammals;
to the spec of parent, this does not produce a child.epitome (clearly
such a beast would be expected to be different anyway).  If user
wanted to refer to the epitome of mammals, he would "with parent" and
reference parent.epitome.  (Not good naming here, sorry.)  
  The primitive operations supplied by a child may replace or
supplement, or both, those supplied by the parent.

Re: OOP & Packages in Ada

[Matthew Heaney]

In article <6b1atp$ngp$1@Masala.CC.UH.EDU>, 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.

If you want just the "primitive" operations of the type to be directly
visible to clients of the child package, then the answer is, yes, they are
already directly visible.  This sort of thing was already true in Ada 83:
derivation from another type makes all the "primitive" operations of the
parent type implicitly declared at the point of declaration of the derived
type.

That means Eat, Sleep, and Breed are directly visible in the Dog package. 
To call the Eat operation of Dog, the client need only refer to the Dog
package, not the parent package (containing type Mammal).

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

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

Well then, the use of inheritence is debatable.  The only reason to use
inheritence at all is because you want to enable polymorphic behavior.   If
you never manipulate objects of type Mammal'Class, then why bother
publically deriving from Mammal?  Better is to create a new root type
(here, Dog), and then privately inherit (if necessary) from Mammal.  To do
otherwise is to create unnecessary coupling.

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

You should never have deep inheritence hierarchies in Ada.  If you do, then
you are doing something wrong.

Here's why.  Ada is not a pure object-oriented language.  It was made for
systems programming, specifically designed to implement systems that have
high reliability requirements.  In such systems, only minimal use (if any)
of heap is allowed.  That is why Ada (and C++) has value semantics by
default.

Other languages, say Java or Eiffel, have reference semantics by default. 
Every Dog object goes on the heap.  In fact every object (the exceptions
are "expanded" objects in Eiffel) goes on the heap, and gets automatically
garbage collected.  This ubiquitous use of the heap is fine, but makes
those languages unsuitable for the class of systems for which Ada was
designed.

But this seemingly innocuous decision to make objects have value semantics
has over-arching consequences for design of software systems in Ada (and
C++).  When I declare an object like this

declare
   My_Dog : Collie;
begin

the compiler has to know how much space to allocate for My_Dog at compile
time.  This makes this module *very* sensitive to changes in ancestor
types.  Every time you touch an ancestor package, the compiler is going to
have to recompile *all* the packages containing the declarations of types
in the Collie hierarchy.

Pure object oriented languages don't have this problem, because the
representation of all objects is the same: it's just a pointer, whose size
is known statically.  That's why the style of type design in pure object
oriented languages favors deep hierarchies (as a reuse mechanism), because
there's essentially no compilation penalty.

But we don't have this luxury in Ada systems.  Any change near the root of
a hierarchy is going to have a potentially massive ripple-effect, because
the compiler has to adjust the size of all statically declared objects of
any descendent type.

Sadly, many Ada (and C++) programmers haven't caught on to this idea.  They
create deep hierarchies because "that's how you do it in Eiffel or
Smalltalk, you know, in a pure object oriented language," but then they
have to recompile the universe every time they make a change.  Worse, they
turn around and blame Ada, and say "Ada compiles are slow."  This isn't an
Ada problem, it's a programmer problem.

That is why I admonish you to create hierarchies that are broad and
shallow, and avoid hierarchies that are deep and narrow.  If you want
reuse, don't use inheritence to effect it, use aggregation (or possibly
private inheritence).  Use public inheritence because you want polymorphic
behavior, because you want to allow different representations for a
classwide object.

I will say it again: do not create deep inheritence hierarchies in Ada.  If
you do, you're not thinking in Ada, and you're doing something very very
wrong.

--------------------------------------------------------------------
Matthew Heaney
Software Development Consultant
<mailto:matthew_heaney@acm.org>
(818) 985-1271

Re: OOP & Packages in Ada

[Jon S Anthony]

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

Re: OOP & Packages in Ada

[Anonymous]

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

Re: OOP & Packages in Ada

[John English]

wanker@exploited.barmy.army wrote:
: Object (Appearance)
:    Organism (Reproduction)
:       Animal (Locomotion)
:          Mammal (Fur_Thickness)
:             Dog (Bark)
:               Collie (Grooming)

: [...lots of big snips...]

: I've probably beat the horse to death on this one, but I wanted
: to make things clear about how I felt.

Hang on. I thought we were talking about Rover the Collie Dog?
Where did the horse come from?  :-)

-----------------------------------------------------------------
 John English              | mailto:je@brighton.ac.uk
 Senior Lecturer           | http://www.it.bton.ac.uk/staff/je
 Dept. of Computing        | ** NON-PROFIT CD FOR CS STUDENTS **
 University of Brighton    |    -- see http://burks.bton.ac.uk
-----------------------------------------------------------------

Re: OOP & Packages in Ada

[Don Harrison]

Matthew Heaney wrote:

: ... (read Dawkins' The Blind Watchmaker, or
:D'Arcy Thompson's On Growth and Form, or anything by Stephen Jay Gould). 

Better still, read Phillip Johnson's "Darwin on Trial" which refutes both. :)

Q: What's the definition of a "vestigal" organ?
A: One whose purpose isn't understood.


Don.
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Don Harrison        doELIDEnh@syd.csa.com.au

Re: OOP & Packages in Ada

[Matthew Heaney]

In article <EnuAD7.217@syd.csa.com.au>, nospam@thanks.com.au wrote:

>: ... (read Dawkins' The Blind Watchmaker, or
>:D'Arcy Thompson's On Growth and Form, or anything by Stephen Jay Gould). 
>
>Better still, read Phillip Johnson's "Darwin on Trial" which refutes both. :)

My point is that systems of any kind evolve, including large software
systems.  The object paradigm facilitates evolution of software systems via
polymorphism: changes don't break existing code.  Let us be reminded of
what John Gall said in Systemantics:

"A complex system that works is invariabley found to have evolved from a
simple system that worked."

and conversely

"A complex system designed from scratch never works and cannot be made to work."

The latter quote aptly describes many software projects.

Yes, there is some religious dogma that repudiates evolution of living
systems, but I think we can all agree that at a minimum large software
systems evolve, and that you better plan for this evolution to happen.

>Q: What's the definition of a "vestigal" organ?
>A: One whose purpose isn't understood.

How many times have you looked at old code that you know you could do
better now, but don't bother changing it because it's "good enough"? 
That's a vestigal organ, and there's nothing to that isn't "understood"
about its behavior at all.

When you're done with Johnson book (I haven't read it yet), then sit down
and read Evolution and the Myth of Creationism, by Tim M. Berra, and The
Panda's Thumb, by Stephen Jay Gould.

Actually, just last night I picked up Dawkin's first book, The Selfish
Gene.  It's on deck right behind the book I'm reading now, Daniel Dennet's
Consciousness Explained.

No entelechy for me thank you very much, I got systems to build.

Re: OOP & Packages in Ada

[Don Harrison]

Matthew Heaney wrote:

:In article <EnuAD7.217@syd.csa.com.au>, nospam@thanks.com.au wrote:
:
:>: ... (read Dawkins' The Blind Watchmaker, or
:>:D'Arcy Thompson's On Growth and Form, or anything by Stephen Jay Gould). 
:>
:>Better still, read Phillip Johnson's "Darwin on Trial" which refutes both. :)

BTW, "both" refers to Dawkins and Gould. I'm not familiar with Thompson's work.

:My point is that systems of any kind evolve, including large software
:systems...  

Yes, that's true of software systems. However, I'm referring to biological 
systems. It's an established fact that organisms can micromutate to accomodate 
changes in their environment. However, it's quite another thing to claim that 
changes in *species* can occur through:

  a) Accumulated micromutations (traditional Darwinism as espoused by Dawkins,
     for example), or
  b) Macromutations (Gould's theory of Punctuated Equilibrium)

through a process called "natural" selection.

Contrary to what many would like to think, neither of these theories have 
been proven.


:Yes, there is some religious dogma that repudiates evolution of living
:systems, ...

My reference is to Gould's book. If you read it, you'll discover that it isn't 
based on "religious dogma". Rather, in assessing the claims of Darwinism,
Johnson has stuck to factual evidence and avoided prior assumptions, including 
those based on religious belief. This is in stark contrast to Dawkins' and 
Gould's writings which reflect numerous unstated assumptions derived from the 
Darwinist belief system. 


:>Q: What's the definition of a "vestigal" organ?
:>A: One whose purpose isn't understood.

My point here is to take issue with your assumption of evolution of biological 
organs as implied by the word "vestigal".

:When you're done with Johnson book (I haven't read it yet), then sit down
:and read Evolution and the Myth of Creationism, by Tim M. Berra, and The
:Panda's Thumb, by Stephen Jay Gould.

I have finished "Darwin on Trial" and intend reading "Evolution: A Theory in
Crisis" by Michael Denton next. I've read parts of Dawkins' "Climbing Mount
Improbable" and Gould's "Ever Since Darwin". If I find the time, I'll take a 
look at Berra. 


Don.
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Don Harrison        doELIDEnh@syd.csa.com.au

Re: OOP & Packages in Ada

[Bob Collins]

In article <Envu3G.LnD@syd.csa.com.au>, nospam@thanks.com.au wrote:

> I have finished "Darwin on Trial" and intend reading "Evolution: A Theory in
> Crisis" by Michael Denton next. I've read parts of Dawkins' "Climbing Mount
> Improbable" and Gould's "Ever Since Darwin". If I find the time, I'll take a 
> look at Berra. 

If you want as clear as explanation as there is as to why
"the impossibility of macroevolution" is an intellectual
crock, try Daniel Dennett's _Darwin's Dangerous Idea_.

-- 
Bob Collins  <mailto:collins@cs.wm.edu>  <http://ratbert.cs.wm.edu>