Re: polymophism

[John Howard <jhoward@sky.net>]

On 21 Nov 1996, James O'Connor wrote:
> I once posted here, a long time ago, that I don't think Ada95 was an OO
> language.

I expect you agree object-oriented programming relates three distinct 
concepts-- data abstraction, inheritance, and polymorphism.  Realize there 
is no general consensus on whether all three concepts must be demonstrated
in the same program to call it object-oriented.

Regardless, Ada 95 is an object-oriented language since it provides 
mechanisms to support all of the three concepts used in object-oriented
programming.  To arrive at that conclusion we must agree on five 
fundamental definitions.

Quoting from the Norman Cohen book, "Ada as a second language, 2nd ed.", 
pp.499-501:
1)
"Data abstraction is the practice of identifying the operations that can 
be used to manipulate a particular kind of data and defining an abstract
data type entirely in terms of the effect of those operations."

2)
"An abstract data type (ADT) consists of a set of values and a set of 
operations for manipulating those values."

3)
"Inheritance is the definition of a new type that is almost the same as
some other, previously defined, type."

4)
"Polymorphism is the definition of operations that apply to more than one
type.  Polymorphic operations are defined for classes of types that have
common properties."

p. 48:
5)
"Objects hold the values used in a computation.  There are two kinds of
objects in Ada-- variables and constants."

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

Your definition of "Object" is different than Ada and alot of other
languages.  Your "Object" is the definition of ADT.  However an ADT does
not have to be implemented to allow inheritance or polymorphism.  
Therefore you are merely advocating a particular interface to a 
specialized ADT which encapsulates data abstraction, inheritance, and
polymorphism together.

Ada 95 provides a mechanism for inheritance by type extension called
derived types.  Using Ada 83 for doing inheritance is more cumbersome.

Ada 95 provides a mechanism for polymorphic programming by tagged types.
Ada 95 allows classwide programming but Ada 83 does not.  For each tagged
type there is a classwide type.  A tagged type other than a classwide type
is called a specific type.  Values of classwide types can be manipulated
by two kinds of polymorphic subprograms-- classwide subprograms and
dispatching subprograms.

Your below example did not demonstrate polymorphism because you neglected 
to declare a tagged type.  I'll try to clarify...

> (I'll try to use example code but I haven't programmed in Ada in
> years...)
>
> package Airplane_Package is
>
******************tag type******
> type AIRPLANE_TYPE is private;
> 
> function Get_Tail_Number (Airplane : AIRPLANE_TYPE) returns String;
> procedure Take_Off (Airplane : AIRPLANE_TYPE);
>
> private
******************tag type******
>   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 and My_TailNumber are Ada objects.  But I believe you are 
searching for an instance of a tagged type.  Here is how to allow them in 
your example:

 type AIRPLANE_TYPE is tagged private; ...
 private
   type AIRPLANE_TYPE is tagged record ...

> 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.
[snip]

1)  An instance of a type is an Ada object.  Ada objects have runtime
    existence.

A derived type is a type declared to be similar to some previously 
declared type, called the parent type of the derived type.
  type Derived is new Parent;

** ** ** ** ** ** ** ** ** ** ** ** ** ** ** ** ** ** ** ** ** ** ** **
A derived type automatically inherits the primitive operations of its     
parent type.  A primitive operation is associated with the type as a
whole.
** ** ** ** ** ** ** ** ** ** ** ** ** ** ** ** ** ** ** ** ** ** ** **

The two primitive operations of the tagged AIRPLANE_TYPE are
  function Get_Tail_Number (Airplane : AIRPLANE_TYPE) returns String;
  procedure Take_Off (Airplane : AIRPLANE_TYPE);

A primitive operation of a tagged type is allowed to be an abstract
subprogram only if the tagged type is declared an abstract type (type ... 
is abstract tagged private;).  An abstract type is supposed to be used as 
the parent type in a number of derived type declarations.  An Ada abstract 
type should not be confused with the term abstract data type.  A type that 
is not an abstract type is called a concrete type.  An abstract type can
provide the interface for an abstract data type thereby allowing multiple 
implementations often conveniently organized as child packages.  Abstract 
types are ideal for defining models to be used as application frameworks.

Ada abstract subprograms are analogous to C++ pure virtual functions.  Ada 
parent types are analogous to C++ base classes.  Ada derived types are 
analogous to C++ derived classes.  A C++ class has two roles kludged 
together-- module encapsulation and the definition of a type.  Those roles 
are distinct with Ada 95.

2)  Ada uses a package for encapsulation.

A package encapsulates the definition of an ADT's data structure and the
implementation of the ADT's operations.  Information hiding is a mechanism
to enforce data abstraction and encapsulation.  Information can be hidden
from other parts of an Ada 95 program by placing it in a package body or
in the private part of a package declaration.


Undeniably, Ada 95 is an OO language since it provides mechanisms to allow 
data abstraction, inheritance, and polymorphism (even some or all concepts 
in the same program).

-- John Howard <jhoward@sky.net>               -- Team Ada  Team OS/2 --