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: oconnor@apci.net (James O'Connor)
Subject: Re: polymophism
Date: 1996/11/23
Message-ID: <575nv7$ike@queeg.apci.net>
X-Deja-AN: 198174358
references: <56q99a$5o3@rc1.vub.ac.be> <56skhq$9cg@hacgate2.hac.com>
 <570f4b$rbu@queeg.apci.net> <3295E624.726B@watson.ibm.com>
organization: Applied Personal Computing, Inc.
reply-to: oconnor@apci.net (James O'Connor)
newsgroups: comp.lang.ada
Date: 1996-11-23T00:00:00+00:00
List-Id: <comp.lang.ada>


In <3295E624.726B@watson.ibm.com>, "Norman H. Cohen" <ncohen@watson.ibm.com> writes:
>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.)
>
Of course they're silly...no argument there.... Usually such arguments are.  They
 predate me being here and will probably follow long after I'm gone.  A question
 such as 'How does Ada do ....' can be answered with a description, LRM reference, 
example code.   A question such the original question that started my answer 
(something like "Is Ada95 really OO or is that just hype" is bound to get an 
opinionated response.  I gave my opinion, based on my reasoning.  I think my 
reasoning is valid, but I neither expect everyone to agree nor feel bad that 
they don't.
  I do want to point out that by saying I don't feel that Ada95 is OO does not 
mean I think any more or less of Ada95.  Languages are tools that we used to 
build systems and software.  Whether Ada95 is called 'truly an OO language' 
or 'support OO principles' isn't as important as 'can I use it to satisfy 
the requirements of the system I'm building' and my opinion of it's (or any
 other languages) 'OO-ness' matters little.

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

Go ahead.  After I posted the original letter, I had a very good email 
conversation with someone who had read it.  In the course of that conversation 
and after rereading my original post and a follow up to it; I realized I hadn't 
done a very good job articulating my position.  (Please...'James' will do fine)
>
>> 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'?)

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

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

Oopss...got to loose with throwing terms around.  What I had in mind was 
that the object (Airplane) holds the state defined by the type.  I would 
like the same type to also declare the operations in the sense that a 'class' 
declaration does in Java or C++.

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;

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)

[Explanation of 'instance based' versus 'class-based' languages deleted]

>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 feel that this leads to Adas "non-OO-ness" but, as I said before, I don't believe
 that means Ada is 'bad'.  I think the packaging notion of grouping like things
 together and providing a special relationship between those things is very 
powerful and wish it was elaborated as well in other languages.  What I would 
like to see is the ability to 'declare a class' - (including state and behavior), and 
then use a package to declare mulitple classes that work together in a defined 
collaboration of classes where the classes within the package would have access
 to each other in ways that those outside the package do not. Right now there are
 two levels of access (so to speak), inside the package and outside the package. 
  I would like to see three: inside the class, inside the package and outside the package.

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

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.

In C++
 anAirplane->TakeOff(); // An operations or responsibility OF anAirplane
 Land (anAirplane);	// An operation ON an Airplane, someone else's responsibility

In this example, with no other context, your disctinction is clear
In Smalltalk

	anAirplane takeOf. 
	self land: anAirplane

Again you can immediately tell that #takeOf is a responsibility of anAirplane
 whereas #land: is someone else's responsibility.

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

Actually the absence of state arises when your objects don't need state.
This is not uncommon in a class hierarchy where some abstract parent
 class defines the state and the common public protocol and the subclasses
 implement that protocol in various ways.  They have already inherited their
 state from their parents; they just use it differently.  A couple of well known 
examples are Smalltalk's Collection and Stream classes.  Collection defines an
 instance variable 'elements' and a common protocol (#add:#addAll: #at:#at:put:, etc...)
 subclasses inherit 'elements' and the common protocol but choose to implement
 those operations differently (Array and String and OrderedCollection and SortedCollection
 and Symbol and Dictionary and....)  Streams act the same way. Stream defines
 'collection' and 'position', but how they are operated on varies (ReadStream,
 WriteStream, FileStream, SocketStream, etc...)  What you are talking about is
 using the class as a "Singleton" instance; what I am talking about is classes 
 that introduce or whose instances need no state to function.  Even objects that have
 no state at all can not be implemented as Singletons (by being classes) 
because oftern those objects are needed as variables of some other object.

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.
>
Sure...but I'm not talking about singletons...just stateless objects. :-)

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

>-- 
>Norman H. Cohen
>mailto:ncohen@watson.ibm.com
>http://www.research.ibm.com/people/n/ncohen


Hey this is fun...

James
oconnor@apci.net