Re: Ada95 OOP Questions

[cosc19z5@Bayou.UH.EDU (Spasmo)]

Thomas Kendelbacher (Thomas.Kendelbacher@erno.de) wrote:
: In article <4tgi88$5fi@Masala.CC.UH.EDU>, cosc19z5@Bayou.UH.EDU (Spasmo) writes:

[Snip]

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

Point well taken, I guess I've just had my view clouded by
other OO languages.  This and my confusion about inheritance
led to the above question.



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

Ok gotcha.  In any case after thinking carefully I do
see the whole view, it's just that to me a total 
merger of data and operations seemed to be a cornerstone
of OOP (that's just the way I was using it), so I really
had a hard time seeing where the inheritance actually
kicked in.


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

Gotcha.  So if I declare any type, tagged or not, then operations
will be inherited and I can refer to them in "child packages"?
This would mean that "inheritance" is pretty consistent regardless
of OO extensions or not eh?


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

Well once again it's just that I was used to one particular way
of doing things which sorta locked me into seeing that as *THE*
way.  Ignorant of me I agree.  The biggest leap was actually
in the realization that the parameter could influence inheritance
which took a while to sink in since it was just a new concept
to me.


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

Well the equality operations are defined for all types
so isn't it just a matter of saying if this = that
in Ada?


[Snip]

Thanks for the assistance.




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



--
Spasmo
"Everyone has secrets, but sometimes you get caught,
 So if it's just between us, my silence can be bought"
	"Blackmail" by Sloppy Seconds