Re: polymophism

[jsa@alexandria (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