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: jsa@alexandria (Jon S Anthony) Subject: Re: polymophism Date: 1996/11/22 Message-ID: X-Deja-AN: 198026928 sender: news@organon.com (news) references: <56q99a$5o3@rc1.vub.ac.be> <56skhq$9cg@hacgate2.hac.com> organization: Organon Motives, Inc. newsgroups: comp.lang.ada Date: 1996-11-22T00:00:00+00:00 List-Id: In article <570f4b$rbu@queeg.apci.net> oconnor@apci.net (James O'Connor) writes: > 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?'. Yes. This is perfectly well defined, simple, and explicit: type Some_Type is .... ... Obj : Some_Type; -- Obj is an object of type Some_Type and "has" all -- the operations of Some_Type (dispatching or otherwise) > To me, at least, an Object must be able to have two things, state > and behavior (data and operations). Obj "has" both of these. > 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. No - this implements what is typically called a "class" in typical OOLs - _not_ an object. > The type declaration is typically a record that describes the names > and types of the attributes of the Object. (I'll try to use example > code but I haven't programmed in Ada in years...) Actually, the type is typically a private type (which may typically be _IMPLEMENTED_ as a tagged/record type) > package Airplane_Package is > > type AIRPLANE_TYPE is private; > > function Get_Tail_Number (Airplane : AIRPLANE_TYPE) returns String; > > procedure Take_Off (Airplane : AIRPLANE_TYPE); > > private > type AIRPLANE_TYPE is record > Tail_Number : STRING (1 .. 20) := ""; > Model_Design_Series : STRING (1 .. 20) := ""; > end record; > > end Airplane_Package; > > with Airplane_Package > procedure Test is > > My_Airplane : Airplane_Package.AIRPLANE_TYPE; > My_TailNumber : STRING (1 .. 20); > begin > My_TailNumber := Airplane_Package.Get_Tail_Number(My_Airplane) > end Test; > > My question is "where's the object?" Presumably you mean "object of type Airplane_Type". It's right there: My_Airplane. How's this any different than in Smalltalk or Eiffel or ..., where you define a class _and then_ declare instances (aka objects) of the class??? > My_Airplane isn't an object because it only defines the state of an > Airplane. It does not define the operations available for the It does neither - it encodes both state and applicable operations. Per object methods (operations) are not defined in Smalltalk, Eiffel, ..., either. There are _some_ OOLs which do this, but none of the "obvious ones". So, you have a rather restrictive notion of "object". One which precludes Smalltalk, Eiffel, Sather, Obj-C, etc. from having objects. Presumably you would say none of these are object oriented either. > Airplane. The package defines the operations. Just like an instance of a class in Eiffel (ST, ...) does not "define the operations available for Airplane. The CLASS 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. First, you are conflating module and type. Which is what most OOLs do. Note that Dylan and CLOS agree with Ada here. Presumably they are not OO either. Second, in most typical "OOLs", a CLASS does not have runtime existence either (certainly not in things like Eiffel, Sather, etc. However, in ST, a class does have runtime existance). > Now the Planes_Trains_And_Automobiles package loses the semblance of > a class because it defines the structure of several different data > types and defines > operations against all of those data type. > > > Another variation would be a "Wrapper" package. Note that in any multiple dispatch "OOL" you will have similar sorts of issues. This is because you can define methods "anywhere" that operate and dispatch on their argument types. There is no "class wall" surrounding these. Presumably these would not be OO either (obvious examples would again be Dylan and CLOS), but most people do think they have much more expressive power than your run of the mill "OOL". > Now who defines the operations for the Airplane? Extended_Airplane... I think you would have serious issues/problems with Dylan and CLOS as well since the exact same situation arises. Maybe they don't have objects either. > I think these examples are sufficiently structured and perfectly > legal to the degree that even Ada95's features of tagged records and > class wide dispatch don't change the fundamental point that Ada > doesn't have objects; Objects that know their state and implement > their behavior. You go further than that. You are arguing that most OOLs don't have objects (per your definition). An instance of an Eiffel class has no knowledge whatsover of its state and no implementation whatsover of any of its "behavior". None. Same with ST, etc. > 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. Per your definitions, basically no typical "OOL" would be an OOL. Also, since you have everything revolving around "class" you have to toss out all prototypical/delegation based "OOLs" as well since they don't even have the concept in any form. Shrug. I prefer to not accept your definition as it seems to have little to do with the term as it is used in common practice. /Jon -- Jon Anthony Organon Motives, Inc. Belmont, MA 02178 617.484.3383 jsa@organon.com