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=-0.3 required=5.0 tests=BAYES_00, REPLYTO_WITHOUT_TO_CC autolearn=no 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: "Norman H. Cohen" Subject: Re: polymophism Date: 1996/11/22 Message-ID: <3295E624.726B@watson.ibm.com> X-Deja-AN: 198106107 references: <56q99a$5o3@rc1.vub.ac.be> <56skhq$9cg@hacgate2.hac.com> <570f4b$rbu@queeg.apci.net> content-type: text/plain; charset=us-ascii organization: IBM Thomas J. Watson Research Center mime-version: 1.0 reply-to: ncohen@watson.ibm.com newsgroups: comp.lang.ada x-mailer: Mozilla 3.0 (Win95; I) Date: 1996-11-22T00:00:00+00:00 List-Id: James O'Connor wrote: > I once posted here, a long time ago, that I don't think Ada95 was an OO language. > I received polite and informed rebuttals. I'll say it again, for the same reasons, and > expect the same response so now hard feelings to anyone around. Thus begins a long discussion of why Ada does not meet this particular writer's definition of an OO language. Such discussions are, generally, silly, because there are so many definitions floating around of what it means to be an OO language. Those who find such discussions important start with the premise, "Whatever it means to be an OO language, it's really good to be one, so let's see if Language X qualifies." A much more useful approach than attaching labels to languages is to outline the benefits for software development and maintenance that are generally considered to result from the use of OO techniques, and see whether Ada makes it easy to achieve those benefits in a stragithforward way. (It will come as no surprise that I firmly believe Ada does so.) Even after stating that it is silly to worry about whether Ada meets James O'Connor's definition of an OOL, however, I find myself compelled to point out flaws in his definition. > 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. 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: > In Ada (83 or 95) the standard mechanism for implementing an Object seems to > be to have a package that wraps a type declaration and a set of operations on > that type. The type declaration is typically a record that describes the names and > types of the attributes of the Object. O'Connor is right that Ada does not have a single syntactic construct that specifies both the state and the behavior of objects of a given type. Rather, a package can contain both a type declaration specifying the state (or, to be precise, a template for the state) and subprogram declarations specifying the behavior of objects of the declared type. So what? This is all the same information found in a "traditional" OO class declaration, but with the keywords arranged differently. [sample of an Ada package providing a type Airplane and a client declaring an object My_Airplane of type Airplane deleted] > My question is "where's the object?" My_Airplane isn't an object because > it only defines the state of an Airplane. It does not define the operations > available for the Airplane. The package defines the operations. But the package > isn't an object (the package doesn't even have runtime existance). In this case > you could say that the package is close to being a class. However this only > really works if you follow a 'One Object -> One Package' rule. My_Airplane does not "define" the state of an Airplane instance, it HOLDS that state. The (format of) the state is DEFINED in the type declaration. Similarly, the "format of the behavior" is defined by the subprogram declarations in the package. Nonetheless, that behavior is a property of the run-time object My_Airplane, in the sense that My_Airplane can only be manipulated through those operations. (In some OO languages, e.g. Self, an object's methods are actually replacable parts of an object's state, an effect that can be achieved in Ada with subprogram pointers. However, other OO languages, such as C++ and Java, only provide the illusion that an object's methods (called "member functions" in C++) are part of its state. C++ and Java methods need not be implemented that way, because all objects of a given class have the same member functions.) 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. O'Connor then objects to the fact that one can write a package Extended_Airplane providing additional operations of Airplane objects and implementing them in terms of the operations provided by the original package Airplane_Package: > Now who defines the operations for the Airplane? Extended_Airplane > defines operations against AIRPLANE_TYPE in the same manner as > Airplane_Package. Clients use Extended_Airplane in the same manner as > Airplane_Package. The only difference is that Extended_Airplane must > build it's operations on publicly available operations in Airplane_Package. > For the rest of the world, Extended_Airplane defines operations for the concept > of 'Airplane' in the same manner as Airplane_Package and Airplane_Package > ceases to be mechansim for implementing operations for 'Airplanes' I don't understand this objection. Any language allows higher-level operations on a class to be defined outside of the class itself in terms of the basic operations provided by the class. Yes, packages are part of the mechanism by which Ada provides the capability that other languages provide through a class definition. And yes, packages can also be used in ways different from classes. So what? > Another example is objects that have behavior but no state. I think Ada95 > can define a a 'null record'; a record with no data so that you can define > a 'tagged null record' that defines a abstract stateless object, but that seems to > me kind of silly to have to define a data structure with no data in order to create > operations that take variables of that data structure (with no data) in order to > say that you have an object. The need for an object with no state only arises in languages in which the only way to encapsulate a group of related operations is to define them in a class. Such a class need only have a single instance, since the absence of state implies that all instances will be identical. In Ada one simply defines a package that provides operations but does not define a type (e.g. the package Ada.Numerics.Elementary_Functions, which provides a set of mathematical functions on type Float). There is no need for creating an illusion that the services provided by such a package are actually provided by some singleton run-time entity. > So I would say that, given good OO design discipline, you can use Ada95 to > implement an OO design in an OO manner, but that Ada95 itself is not an OO language. Fine. As long as we are agreed that Ada makes it easy to implement an OO design in an OO manner, who cares what labels you attach to the language? (Personally, I think that a good definition of an OO language is one that makes it easy to implement an OO design in an OO manner, and that any other definition is misleading, but I certainly recognize your right to define things misleadingly if it pleases you.) -- Norman H. Cohen mailto:ncohen@watson.ibm.com http://www.research.ibm.com/people/n/ncohen