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,1dc0d0f1c69afb5a X-Google-Attributes: gid103376,public From: mheaney@ni.net (Matthew Heaney) Subject: Re: polymophism Date: 1996/11/22 Message-ID: X-Deja-AN: 198227500 references: <56q99a$5o3@rc1.vub.ac.be> <56skhq$9cg@hacgate2.hac.com> <570f4b$rbu@queeg.apci.net> <3295E624.726B@watson.ibm.com> <575nv7$ike@queeg.apci.net> content-type: text/plain; charset=ISO-8859-1 organization: Estormza Software mime-version: 1.0 newsgroups: comp.lang.ada Date: 1996-11-22T00:00:00+00:00 List-Id: In article <575nv7$ike@queeg.apci.net>, oconnor@apci.net (James O'Connor) wrote: >>> The reason I object to Ada being called OO is that I don't think Ada has an >>> entity, thing, whatever that you can point to and say "that's an object". Before >>> you get into whether Polymorphism or Inheritance (single or multiple, >>> implementation or interface), I think your first question should be >>> 'can I create an object?'. To me, at least, an Object must be able to have >>> two things, state and behavior (data and operations). >> >>Of course Ada has objects. The RM even calls them objects. >"Of course tool X has feature Y because the sales brochures say > it does" - Sorry. I must take issue with this line of argument. (How many versions > of PowerBuilder have been 'finally OO'?) A poor argument. An object in Ada has state and behavior, just as Norm pointed out. If you have trouble identifying objects in Ada, then this simple rule will help. Given a declaration such as O: T; the object is that little thing to the left of the colon. Them thar objects in Ada're pretty damn hard ta find, huh? > >>Every >>object has state (i.e., a value) and it has behavior (certain operations >>that can be applied to it). However, the objects I am talking about are >>run-time entities--what are called instances of a class in some other OO >>languages. It appears that O'Connor is using the term "object" sloppily >>to refer to a textual entity--a class definition: > >That's pretty much precisely what I'm looking for, a single entity or structure >that you can say 'That defines what my object looks like' or 'that defines my class >structure which my objects are created from'. My sticking point is that Ada >separates that 'declaration' into two separate structures: The package and the type > declaration. The type declaration defines the state of the object but not the >behavior. The package defines operations, which could be operations against that > type, or against other types in that same package or ...whatever grouping of > operations you need. Time and time again I've met people who don't understand packages. Even Peter Wegner got it wrong. It's all very simple: In Ada, the type and the module are orthogonal language constructs. There. That's not so hard, is it? In Ada, a package does NOT define an abstract data type. In Ada, an abstract data type, denoted by the keyword "private", defines an abstract data type. That's right folks! I will say it again. A package does not implement an abstract data type. Ada quite deliberately separated the module and the type. This is a feature of the language, not a defect. People constantly misunderstand this. The Ada package was created to give the programmer explicit control of namespace. The package is not unlike the namespace construct in C++. In C++, I can declare several classes within the same namespace. In Ada, I can declare several abstract data types within the same package. I frequently hear admonishments to "only declare 1 private type per package." This is poor advice. If I did that, then my global namespace would be cluttered with so many packages that I wouldn't be able to make sense of it all, so I would need some other, higher-level way of managing the packages. But that's the whole purpose of packages in the first place. The proper way to state the guideline is as follows: "declare closely-related types in a single package." This is a requirement, not just a guideline, if my types are mutually dependent. In Ada 95, we may further state the guideline: "declare closely-related packages as part of a single subsystem, ie, as children of a common parent package." The hierarchal package feature allows me to maintain intellectual control of global namespace. >package Airplane_Package is > > type AIRPLANE_TYPE is class > Tail_Number : STRING ( 1.. 20); > procedure Take_Off (); --Operation *Of* an AIRPLANE_TYPE > end class; > > type TERMINAL is class > Call_Frequency : FREQUENCY; > end class; > > -- Now define an operation *ON* AIRPLANES and TERMINALS > procedure LandAt (anAirplane : AIRPLANE; aTerminal : TERMINAL); > >end; "On" or "of": who cares? We're in the noise here. >All I'm missing is some 'scope' keywords to define what operations are private > to the class; what operations are allowed from within the package,and what >operations are visible outside the package (Something like 'private public and export'; > I don't know, maybe you could use the existing spec-body structure) The operations declared in the public part of the spec are, well, public, and callable by clients of objects of the type. Operations declared in the private part of the spec are callable by children of the package. Operations declared in the package body (or perhaps in a private child with'd by the body) are private, and only visible in the body >>While Ada certainly allows a one-type-per-package rule, it does not >>enforce it (although it is easy to write a tool to enforce it if you are >>so inclined). The capability of defining more than one type in a >>package is often useful. If O'Connor feels that the ability to do this >>makes Ada non-OO, I view this as a weakness of (what he calls) OO >>techniques and a strength of Ada. I would state this even more strongly: the ability to declare more than one (closely-related) type in a package is a VERY GOOD THING. And no, I don't buy the argument that this is any less OO. The "primitive operations" of a type are those operations declared in the same package as the type declaration. This is not a moral issue. This is not an issue about greater or lesser object-oriented-ness. It's simply how you declare an abstract type in Ada. If you want to have a debate about whether this is a good thing or a bad thing, then we can have a debate about differences in language syntax. But please don't turn it into an argument about "this is not as object-oriented." >This objection comes from the results that I think it muddies the distinction between > operations *of* an object and operations *on* or *using* an object. Operations > *of* the object are operations that your analysis or design has decided are the > responsibility of that object, versus operations *using* an object that are usually >someone else responsibility that require the given object in order to be completed. Yawn. >Airplane_Package_One.Take_Off(Airplane); >Airplane_Package_Two.Land(Airplane); > >Now the distinctions is blurred because you cannot tell whether either >Take_Off() or Land() are operations of an Airplane or operations that happen > to use an airplane. This, to me, is because the definition of what an Airplane > *is* (the type declaration) doesn't declare what an airplane *does*. The >package declares what the Aircraft does, or to be nitpicky, the package > declares what can be done to the Aircraft. This is incorrect. "What an airplane does" is defined as the primitive operations of the type (or, if you prefer, the "methods of the class"). And they are right there in the same package as the type declaration. What's the problem? And no, the package does NOT declare what can be done to the aircraft. The abstract data type declares what can be done to the aircraft. A package is not a type. If you don't like this, well, there's not a lot for us to debate. It's a feature of Ada. Bertrand Meyer said in his "steps to object-oriented happiness" that to be trully object-oriented then the class and the module are the same. But this a silly. You need a way to manage global namespace somehow. (Interesting, because he later added a namespace construct. Perhaps Ada got it right after after all, eh, Bertrand?) >Ah....I was agreeing with you right up to the last punch :-) >I'm not trying to be misleading, to myself or anyone else. I hope I've been a little > clearer here than I was before. Other than that I would agree that you can use >Ada to implement an OO design in an OO fashion; which is probably more important > than whether Ada fits my (or anyone's) definition of being 'truly OO'. I would > counter about the 'easy' qualifier. My language-of-choice is Smalltalk and I think, > compared to Smalltalk, Ada is horribly complicated. But, hey...that's me. I will paraphrase a quote from Jean Ichbiah, who said that "When someone doesn't like your language, they don't directly say that they don't like your language. They say that it's too complex." -------------------------------------------------------------------- Matthew Heaney Software Development Consultant mheaney@ni.net (818) 985-1271