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.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,900edaa189af2033 X-Google-Attributes: gid103376,public From: cosc19z5@Bayou.UH.EDU (Spasmo) Subject: Re: Ada95 OOP Questions Date: 1996/07/31 Message-ID: <4tor2u$ksg@Masala.CC.UH.EDU> X-Deja-AN: 171305464 references: <4tgi88$5fi@Masala.CC.UH.EDU> <4thu7u$ld3@mailsrv2.erno.de> organization: University of Houston newsgroups: comp.lang.ada Date: 1996-07-31T00:00:00+00:00 List-Id: 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