Re: polymophism

[oconnor@apci.net (James O'Connor)]

In <56skhq$9cg@hacgate2.hac.com>, ddavenpo@redwood.hac.com (Darren C Davenport) writes:
>AGBOH CHARLES (cagboh@vub.ac.be) wrote:
>
>
>: How does ada support polymorphism. What does the discriminant play in task
>: unit declarations, tagged objects, etc..
>
>: Is ada95 really an object oriented langauge or is it just a good attempt to
>: be one?   
>
>: active ada student and fun.
>
>: p.s Barnes is not clear on the following points ( to me )
>
>See http://www.adahome.com/LRM/95/Rationale/rat95html/rat95-p2-4.html
>
>Darren

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.

I want to make it clear that I don't intend this as a criticism of the Ada 
language itself.  This is a disgreement with the practice of calling it an OO 
language.  In the same vein of C++, I still consider it a hybrid language; capable
of being programmed in an OO style if the programmer wishes, but not OO in itself.
(I have other criticisms of Ada95, but that's not the point here).

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

 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.  (I'll try to use example code but I haven't
programmed in Ada in years...)

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

package Planes_Trains_And_Automobiles
	
	type PLANE_TYPE is private;
	type TRAIN_TYPE is private;
	type AUTO_TYPE is private;

	--.... operations for planes, trains, and automobiles

	private

	-- ...declarations of plane trains and automobiles

end Planes_Trains_And_Automobiles;

procedure Test_Two is

	Airplane : Planes_Trains_And_Automobiles.PLANE_TYPE;
	Train : Planes_Trains_And_Automobiles.TRAIN_TYPE;
	Car : Planes_Trains_And_Automobiles.CAR_TYPE;

begin

	Planes_Trains_And_Automobiles.Take_Off (Airplane);
	Planes_Trains_And_Automobiles.Leave_Station(Train);
	Planes_Trains_And_Automobiles.Start (Car)

end Test_Two;

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.

with Airplane_Package;
package Extended_Airplane is

	procedure Wash_Airplane (Airplane : Airplane_Package.AIRPLANE_TYPE);

end Extended_Airplane;

with Extended_Airplane;
with Airplane_Package;
procedure Test_Three is
	My_Airplane : Airplane_Package.AIRPLANE_TYPE;

begin
	Extended_Airplane.Wash_Airplane (My_Airplane);

end

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'

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.

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.

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.

Thank you,

James O'Connor
oconnor@apci.net