Re: Ada95 OOP Questions

[Thomas.Kendelbacher@erno.de (Thomas Kendelbacher)]

In article <4tgi88$5fi@Masala.CC.UH.EDU>, cosc19z5@Bayou.UH.EDU (Spasmo) writes:
>Well here's the thing though, from what I'm seeing when you
>use the package you'd need to pass the parameters to the
>subprograms rather than having the data encapsulated.  For
>instance in C++ you'd do the following:
>
>	Person p;
>	p.walk();
>	p.talk();
>	p.eat();
>
>But with the above you'd do something like the following:
>(Any Ada code provided may be slightly erroneous, I just want
>to give a general idea of what I think I understand hence not
>checking much).
>
>with Persons;
>procedure Main is
>	P : Persons.Person;
>begin
>	Persons.Walk(P);
>	Persons.Talk(P);
>	Persons.Eat(P);
>end Main;
>
>Correct me if I'm wrong on this.  So you're still passing parameters
>which means that data and subprograms are still 2 different entities
>which sorta hurts the abstraction, rather than in say C++ where 
>you've got a unified object.   

See it from this point of view: It's just a different syntax for the
same thing ("p.walk()" vs. "Walk(P)"), and putting the object P in front
is just some syntactic sugar in C++ which is translated basically to the
same code - a reference to the object is passed to the function as its
first parameter.

>That's pretty much what I was talking about.  I'm not saying that
>one is necessarily worse than the other, I was just wondering if
>there was a rationale for doing it that particular way in Ada
>rather than a unified object that was like a combination of 
>data and subprograms that enabled it to smoothly simulate an
>entity?

The Ada way of writing this comes from the tradition of "abstract data
types," where a type is defined by the operations declared on it.
So, there's definitely a conceptual connection between data and subprograms.

>Also there's another slight difference -- inheritance.  From
>what I'm seeing, if we wanted to create say a SuperPersons
>package that inherited from persons we'd create a new package
>called SuperPerson, then we'd with the Persons package, and
>provide "wrappers" for everything defined in the Persons
>package right?  Then we'd of course inherit from the data
>types and add in any new functionality that we wanted to,
>am I correct?
>
> [.. example recoding the Persons operations for a derived type ..]
>
>Am I correct or can we in fact inherit operations without manually
>providing wrappers for the predecessors?

The latter is true: Even back in Ada 83, a derived type automatically
inherited all operations declared with the original type (in line with
the view of a type as "abstract data type"; the derived type would be
meaningless without the operations!)  This was of course preserved
by Ada 95; the difference is that Ada 95 now has tagged types, while
Ada 83 derived types were always incompatible with their parent types
(save by explicit conversion), and data extension was not directly
supported.

>Well what I learned in C++ was that "class" referred to the declaration/
>definition, whereas an object is an instance of a class.  So using
>my old example, Person is a class, but p is an object since it's an
>instance of Person.  Still that is kinda moot since we're more concerned
>with Ada rather than C++.  I'll look at Question 5.1 again (I skimmed
>over certain parts of the FAQ last time I read it which was when
>I was trying to find out more about Ada to see whether or not I'd
>want to program in it).

What's the big difference here? The type corresponds to the class, as it defines
public/private data and operations, and each value of the type (e.g. stored in a
variable) corresponds to an instance. It's not so much different from your C++
example: You wrote that in a C++ statement like "p.walk()", p "is" a Person
object; but to be exact, it is but a _name_ for the actual object (a variable,
just like in Ada.)

There is an essential difference between objects in C++ and Ada, though; in Ada,
you can't test for object identity as easily, like writing "this == that" in C++
(except if you explicitly switch to access types.) This can be a nuisance if
you're used to OO languages which support object identity directly, like C++ or
Smalltalk.
That's also a heritage from the abstract data type concept, whose mathematical
foundations don't deal with "identity" but with "equivalence."

-- 
Thomas Kendelbacher   |   email : Thomas.Kendelbacher@erno.de
DASA RI / Abt. RIT14  |   voice : +49 421 539 5492 (working hours)
Postfach 28 61 56     |      or : +49 421 57 04 37 (any other time)
D-28361 Bremen        |     fax : +49 421 539 4529 (any time)
Germany