polymophism

polymophism

[AGBOH CHARLES]

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 )

Re: polymophism

[Darren C Davenport]

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

Re: polymophism

[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

Re: polymophism

[Mike Stark]

James O'Connor wrote:
> 
<snip>
> 
>  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.

A better question might be "where's the class?"  The answer is that your
private record type is analogous to a C++ or Java class (can't speak for
any other languages), with the components representing instance
variables and "primitive operations" the member functions.  The
primitive operation is a concept added for Ada 95, and it is one in the
same package as your record type that has an argument of that type. 
Then My_Airplane in procedure test is indeed an object, although you
could also create

type Airplane_Ptr is access Airplane_Type;  -- in Airplane_Package

and

  My_Airplane: Airplane_Package.Airplane_Pointer := new
Airplane_Package.Airplane;

to allocate an object.

To be truly analogous to a class in C++ or Java, you need to use the Ada
95 "tagged" keyword to make types extendable, and class-wide programming
to define dispatching operations.  I will leave the description of these
features to the experts.

This is more than a theoretical discussion.  I have been doing some
prototyping with 
AppletMagic, a tool that compiles Ada into Java byte codes.  When you
run the "javap"
command to disassemble a class file into Java source, Ada code
containing a tagged 
record maps directly to a Java class.

Mike

Note I don't want to get into the fruitless religious war over whether

The_object.Do_something (now); 

or 

Do_Something (The_Object, Now)

is better.

Re: polymophism

[Norman H. Cohen]

Mike Stark wrote:

>                                                             The
> primitive operation is a concept added for Ada 95, 

Actually, it's very nearly the same thing that was called a "derivable
subprogram" in Ada 83.

(Other than that nit, I agree with what Mike has to say.)


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

Re: polymophism

[Klaus Brouwer]

> Note I don't want to get into the fruitless religious war over whether
> 
> The_object.Do_something (now);
> 
> or
> 
> Do_Something (The_Object, Now)
> 
> is better.

Would be better, since 

[The_Object do_someting:now]

is best.


Regards,
	Klaus Brouwer

Re: polymophism

[James O'Connor]

In <32957EB9.17AF@kafka.informatik.uni-stuttgart.de>, Klaus Brouwer <brouwer@kafka.informatik.uni-stuttgart.de> writes:
>> Note I don't want to get into the fruitless religious war over whether
>> 
>> The_object.Do_something (now);
>> 
>> or
>> 
>> Do_Something (The_Object, Now)
>> 
>> is better.
>
>Would be better, since 
>
>[The_Object do_someting:now]
>
>is best.
>

That looks like Smalltalk....except it won't work unless you do

[The_Object do_someting:now] value.
[The_Object do_someting:now] fork.
myBlock := [The_Object do_someting:now]

Somthing like that....

My object wasn't based on whether The_object.Do_something (now); as in C++ 
or Java  or Do_Something (The_Object, Now); as in Ada is a better way of 
expressing the request of an object to perform some operation.  My object was 
that Do_Something (The_Object, Now); obscures  whether you are performing
 an operation *of* The_Object or *on* the object, or an operation that happens to
 *use* The_Object.

>
>Regards,
>	Klaus Brouwer


James O'Connor
oconnor@apci.net

Re: polymophism

[Richard Riehle]

On Fri, 22 Nov 1996, Klaus Brouwer wrote:

in response to the following, 


> > Note I don't want to get into the fruitless religious war over whether
> > 
> > The_object.Do_something (now);
> > 
> > or
> > 
> > Do_Something (The_Object, Now)
> > 
> > is better.

you said,

> Would be better, since 
> 
> [The_Object do_someting:now]
> 
> is best.

which leads me to wonder if you think Russian is a better language
than Chinese because the grammar and syntax of Russian more closely
follows your preference in programming syntax?  

These arguments about syntax are generally pretty much nonsense since 
there is no such thing as a "natural" order in language.  There is simply
the order we have learned in our native language and the biases inherent
in having no knowledge of a radically different language.  

This cultural bias shows up all the time by evaluating programming
languages according to syntactic features while ignoring the importance of
expressibility.  The phenomenom is not new. It manifests
itself as an inhibitor in students trying to learn the spoken language of
another culture when they continually look  for similarities to the
language they already know. 

Richard Riehle

Re: polymophism

[Norman H. Cohen]

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

Re: polymophism

[James O'Connor]

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

Re: polymophism

[Matthew Heaney]

In article <575nv7$ike@queeg.apci.net>, oconnor@apci.net (James O'Connor) wrote:

>>> 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'?)

A poor argument.  An object in Ada has state and behavior, just as Norm
pointed out.

If you have trouble identifying objects in Ada, then this simple rule will
help.  Given a declaration such as

O: T;

the object is that little thing to the left of the colon.

Them thar objects in Ada're pretty damn hard ta find, huh?

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

Time and time again I've met people who don't understand packages.  Even
Peter Wegner got it wrong.  It's all very simple:

In Ada, the type and the module are orthogonal language constructs.

There.  That's not so hard, is it?

In Ada, a package does NOT define an abstract data type.  In Ada, an
abstract data type, denoted by the keyword "private", defines an abstract
data type.

That's right folks!  I will say it again.  A package does not implement an
abstract data type.

Ada quite deliberately separated the module and the type.  This is a
feature of the language, not a defect.

People constantly misunderstand this.  The Ada package was created to give
the programmer explicit control of namespace.

The package is not unlike the namespace construct in C++.

In C++, I can declare several classes within the same namespace.  In Ada, I
can declare several abstract data types within the same package.

I frequently hear admonishments to "only declare 1 private type per
package."  This is poor advice.  If I did that, then my global namespace
would be cluttered with so many packages that I wouldn't be able to make
sense of it all, so I would need some other, higher-level way of managing
the packages.  But that's the whole purpose of packages in the first place.

The proper way to state the guideline is as follows: "declare
closely-related types in a single package."  This is a requirement, not
just a guideline, if my types are mutually dependent.

In Ada 95, we may further state the guideline: "declare closely-related
packages as part of a single subsystem, ie, as children of a common parent
package."  The hierarchal package feature allows me to maintain
intellectual control of global namespace.

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

"On" or "of": who cares?  We're in the noise here.

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

The operations declared in the public part of the spec are, well, public,
and callable by clients of objects of the type.

Operations declared in the private part of the spec are callable by
children of the package.

Operations declared in the package body (or perhaps in a private child
with'd by the body) are private, and only visible in the body

>>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 would state this even more strongly: the ability to declare more than one
(closely-related) type in a package is a VERY GOOD THING.

And no, I don't buy the argument that this is any less OO.  The "primitive
operations" of a type are those operations declared in the same package as
the type declaration.

This is not a moral issue.
This is not an issue about greater or lesser object-oriented-ness.
It's simply how you declare an abstract type in Ada.

If you want to have a debate about whether this is a good thing or a bad
thing, then we can have a debate about differences in language syntax.  But
please don't turn it into an argument about "this is not as
object-oriented."


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

Yawn.


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

This is incorrect.  

"What an airplane does" is defined as the primitive operations of the type
(or, if you prefer, the "methods of the class").  And they are right there
in the same package as the type declaration.  What's the problem?

And no, the package does NOT declare what can be done to the aircraft.  The
abstract data type declares what can be done to the aircraft.

A package is not a type.  If you don't like this, well, there's not a lot
for us to debate.  It's a feature of Ada.

Bertrand Meyer said in his "steps to object-oriented happiness" that to be
trully object-oriented then the class and the module are the same.  But
this a silly.  You need a way to manage global namespace somehow. 
(Interesting, because he later added a namespace construct.  Perhaps Ada
got it right after after all, eh, Bertrand?)

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

I will paraphrase a quote from Jean Ichbiah, who said that "When someone
doesn't like your language, they don't directly say that they don't like
your language.  They say that it's too complex."

--------------------------------------------------------------------
Matthew Heaney
Software Development Consultant
mheaney@ni.net
(818) 985-1271

Re: polymophism

[Joachim Durchholz]

donh@syd.csa.com.au wrote 25.11.96:

> You may be thinking of clusters (which aren't part of the language). These
> serve only to group classes into subsystems as an administrative convenience
> and have no semantic significance.

Though clusters have been declared not to be part of the language, they  
really are.
After all, it is the *compiler* that declares an error if it can't find a  
class because it has been renamed via cluster configuration.

Or, if you don't believe in a proof by "the compiler complains" (a  
standpoint that I usually share):
Take away the cluster configuration from a set of classes. What's left is  
a set of classes with lots of undefined and ambiguous names, because the  
renamed clusters no longer exist under their expected names.

Besides, I don't feel quite at home with the class = module requirement.  
There are useful libraries that consist of dozens of tiny classes, some  
containing nothing more than a few invariant or constant definitions.   
Such classes have too fine granularity to allow easy understanding of a  
system; you need larger units. I think the Cluster concept fill that gap  
(and quite well, too).

Regards,
-Joachim

--
Looking for a new job. Resume available on request. WWW version of resume
available under http://www.franken.de/users/herold/jhd/resume/index.html

Re: polymophism

[Don Harrison]

Joachim Durchholz writes:

:donh@syd.csa.com.au wrote 25.11.96:
:
:> You may be thinking of clusters (which aren't part of the language). These
:> serve only to group classes into subsystems as an administrative convenience
:> and have no semantic significance.
:
:Though clusters have been declared not to be part of the language, they  
:really are.
:After all, it is the *compiler* that declares an error if it can't find a  
:class because it has been renamed via cluster configuration.

Yes, renaming clauses in clusters *do* consitute part of the 'program'
and convey essential semantics. I stand corrected. Such renaming effectively
de-overloads class names.

:Besides, I don't feel quite at home with the class = module requirement.  

I think this is still okay so long as you define a facade class, where 
needed, to provide a common interface to a cluster of classes. This delivers 
the scalability needed for large systems.

:There are useful libraries that consist of dozens of tiny classes, some  
:containing nothing more than a few invariant or constant definitions.   
:Such classes have too fine granularity to allow easy understanding of a  
:system; you need larger units. 

Agree.

I think the Cluster concept fill that gap  
:(and quite well, too).

Agree (if used with facades). What Eiffel does *not* need (and can do 
without), IMO, is a package/namespace mechanism. Clusters are a more flexible 
solution for Eiffel because they contain only configuration information and 
are defined in separate files to classes. Consequently, clusters and classes 
can be changed independently and moving class texts is not necessary to 
include/exclude them.


Don.
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Don Harrison             donh@syd.csa.com.au

Re: polymophism

[Don Harrison]

Matthew Heaney writes:

:Bertrand Meyer said in his "steps to object-oriented happiness" that to be
:trully object-oriented then the class and the module are the same.  But
:this a silly.  You need a way to manage global namespace somehow. 
:(Interesting, because he later added a namespace construct.  

You may be thinking of clusters (which aren't part of the language). These 
serve only to group classes into subsystems as an administrative convenience
and have no semantic significance.


Don.
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Don Harrison             donh@syd.csa.com.au

Is Ada an OO Language? (was => Re: polymophism)

[Richard Riehle]

On Fri, 22 Nov 1996, Norman H. Cohen wrote:

in response to 

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

  [ snipped a long and thoughtful dialogue ]

  Dr. Cohen concludes with this excellent  observation:

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

  I have been wondering recently (only to discover I am not alone in so
  wondering) whether our current devotion to the notion of object is not
  leading us down a blind alley.  Certainly, the fundamental idea of
  "object" has been useful, but it may also seduce us into excessive
  dependence on a concept that is, by its nature, self-limiting. Moreover,
  though the mechanisms and structures we associate with objects may
  be useful, perhaps they too are self limiting.  For example, as we  
  debate to virtue of single-inheritance versus multiple-inheritance
  (only one example) we can often miss the point of what we are actually
  doing with software .  

  This is not to suggest returning to the old days before we thought
  about software in terms of objects.  It simply is a question about
  the potential limitations inherent in our commonly accepted view
  of software objects. Perhaps the notion of object is too small an
  idea.  

  Richard Riehle

  

Re: Is Ada an OO Language? (was => Re: polymophism)

[James S. Rogers]

Richard Riehle wrote:
> 
>   This is not to suggest returning to the old days before we thought
>   about software in terms of objects.  It simply is a question about
>   the potential limitations inherent in our commonly accepted view
>   of software objects. Perhaps the notion of object is too small an
>   idea.
> 

If objects are to model real world entities then there must be a real
subset of all objects which are independent units capable of acting
asynchronously with their environment and synchronously with each
other.  This means that many objects are best implemented as tasks.  

This leads to the further realization that some objects represent
active entities while others represent resources.  The resources
can be modeled in Ada as protected types.  The active objects can
be modeled as tasks.  The active objects interact with each other
either directly, in synchronous activities (rendevous) or through
asynchronous competition for resources (protected types).

The limitation of this approach is that it is not always optimal
for performance.  This accurately models how real entities behave.
They also exhibit a similar sub-optimal performance.  We often find
ourselves trying to develop near perfect models of very imperfect
reality.  Perhaps we can more easily achieve accurate models if
we intentionally accept and exploit the sub-optimal nature of reality.

This view of objects extends the older view of objects as mere
associations of state and function which communicate via messages.
Independently executing objects communicate indirectly through the
contention for resources.  These objects have no need of knowledge
of each other.  They only need to know about the resource and its
current availability.  Nonetheless, these objects do communicate
with each other.  They influence each others behavior through
competition for limited resources.

When these objects interact directly they form communities.
Object communities can only occur among objects which have a direct
knowledge of each other.  Objects within a community can also 
compete for resources, or even share resources.  Communities can
only compete for resources or communicate through commonly accessed
resources.  Once communities gain direct knowledge of each
other they cease to be independent communities.  Instead they form
a larger combined community.

From this point of view I would say that Ada and Java are more
object oriented than Eiffel or smalltalk. Of course, this definition
of an OO language is no more useful than the one which started this 
thread.


Jim Rogers
-------------------

Team Ada

Re: polymophism

[John Howard]

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

Re: polymophism

[Robert I. Eachus]

In article <570f4b$rbu@queeg.apci.net> oconnor@apci.net (James O'Connor) writes:

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

   First? of probably many polite informed rebuttals. ;-)

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

    If you want to define an OO-language as one which has stateful
objects, and associated operations on the object, you should have no
objection to Ada 83 and 95 as OO languages.  The problem you have is
one of seeing the forrest for the trees.  In Ada the fundamental
abstraction is named "type."  Every object has a type, but as you are
aware, there is no single set of operatations associated with a type.
But this is only because, operations are associated with the view of a
type, to allow things in Ada that are not allowed in many other OO
languages.

    But most of those differences come up extremely rarely.  The one
that does often show up is the two (main) different views of a private
type.  Most of the time the model that works extremely well in Ada is
that a type defines a set of objects, and a set of operations.  (A
class wide type contains all the objects in the hierarchy rooted at
the base type, and the operations of the base type.)  Even limited
private types have some associated operations defined at the point of
declaration, and derived types, which are common in OO programming
have lots of implicitly declared operations.

    Now it is true that in Ada it CAN be harder to determine the set
of predefined operations for a type in than in C++.  However, when
programs get large, it is much EASIER to determine the set of
predefined operations in Ada 95 than in C++.  (This occurs because Ada
class hierarchies are typically bushier than in other OO
languages--not as high/deep, but with more branches at each level.
Types that are easily defined as siblings in Ada are often defined as
parent and child in C++ or Smalltalk.)

--

					Robert I. Eachus

with Standard_Disclaimer;
use  Standard_Disclaimer;
function Message (Text: in Clever_Ideas) return Better_Ideas is...

Re: polymophism

[Jon S Anthony]

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

Re: polymophism

[Robert A Duff]

In article <JSA.96Nov21224946@alexandria>,
Jon S Anthony <jsa@alexandria> wrote:
>...  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.

In common practice, "object oriented" simply means "good".  ;-)

- Bob

Re: polymophism

[Jon S Anthony]

In article <E19v7y.25K@world.std.com> bobduff@world.std.com (Robert A Duff) writes:

> In article <JSA.96Nov21224946@alexandria>,
> Jon S Anthony <jsa@alexandria> wrote:
> >...  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.
> 
> In common practice, "object oriented" simply means "good".  ;-)
> 
> - Bob

Can't argue with that! :-)  Even when it at times is actually just plain
 "bad"...

/Jon

-- 
Jon Anthony
Organon Motives, Inc.
Belmont, MA 02178
617.484.3383
jsa@organon.com

Re: polymophism

[Robert B. Love]

In <577c07$r4t@queeg.apci.net> James O'Connor wrote:
> In <32957EB9.17AF@kafka.informatik.uni-stuttgart.de>, Klaus Brouwer 
<brouwer@kafka.informatik.uni-stuttgart.de> writes:
> >> Note I don't want to get into the fruitless religious war over 
whether
> >> 
> >> The_object.Do_something (now);
> >> 
> >> or
> >> 
> >> Do_Something (The_Object, Now)
> >> 
> >> is better.
> >
> >Would be better, since 
> >
> >[The_Object do_someting:now]
> >
> 
> That looks like Smalltalk....except it won't work unless you do

Don't know about smalltalk but it is valid Objective-C.

----------------------------------------------------------------
Bob Love, rlove@neosoft.com (local)        MIME & NeXT Mail OK
rlove@raptor.rmnug.org  (permanent)        PGP key available
----------------------------------------------------------------

Re: Is Ada an OO Language? (was => Re: polymophism)

[Robert I. Eachus]

In article <Pine.GSO.3.95.961125130229.25064B-100000@nunic.nu.edu> Richard Riehle <rriehle@nunic.nu.edu> writes:

   > This is not to suggest returning to the old days before we thought
   > about software in terms of objects.  It simply is a question about
   > the potential limitations inherent in our commonly accepted view
   > of software objects. Perhaps the notion of object is too small an
   > idea.  

   About a dozen years ago I was trying to explain to a new Ada
programmer what he wasn't doing right.  (It wasn't wrong just--not
right.)  I said something like:

   "The problem is that you are trying to model the solution, and you
should actually be modelling the problem domain."

   When what I had said sunk in, I excused my self to go make sure I
had it right.  (And for Ada I did.)

   The solutions (and the problems) are a moving target, but Ada
allows you to build--at very little implementation cost--models of the
domain in which you are working.  Once you have a good domain model,
many solutions can be stated--and coded--in a few lines.

   I just ran into the advantages of this again.  Some of the code I
wrote for the ADAR project used a model of picture strings that did
not agree with the final Ada 95 standard.  Fixing the code required
lots of effort to find out what needed to be changed--that part of the
standard is certainly not simple--and I worked on keeping it as simple
as possible.  However, most of the changes were one-liners that were
immediately obvious once I knew where to look, and whether or not
there was a bug.  (This is not to say I didn't find a couple of my own
bugs, but for the most part the effort was deciding whether a given
string was legal or not.)

   That code has two scanners and two parsers--one set for numeric
values, one for picture strings.  If I had not structured the code to
correspond to the problem domain models, it would have been almost
impossible to figure out where to look.

   I think the longest time between actually characterizing a problem
and putting my finger on the fix was about ten minutes.  I do have a
debug facility built in to the picture string parser, but I never even
used the debugger that supplied with the compiler.  (Characterizing
the bugs involved things like finding that the grammar rejected
pictures that had floating currency symbols using ##... but not $$...,
and had a sign but didn't have any digits after the decimal point.)

   Incidently, one of the functions has fourteen return statements.
Horrible design?  NO!  The spaghetti nature of the return code is
forced by the specification.  Given that the best thing to do is
reflect the problem space in the code.  If I need to add a fifteenth
case, it would be relatively easy.

--

					Robert I. Eachus

with Standard_Disclaimer;
use  Standard_Disclaimer;
function Message (Text: in Clever_Ideas) return Better_Ideas is...