Re: polymophism

[mheaney@ni.net (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