Newsgroups: comp.object,comp.lang.smalltalk,comp.lang.ada,comp.lang.c++
Path: cantaloupe.srv.cs.cmu.edu!europa.chnt.gtegsc.com!news.sprintlink.net!hookup!news.kei.com!world!bobduff
From: bobduff@world.std.com (Robert A Duff)
Subject: Re: Ada95 not OO (was Re: Has C++ had its day?)
Message-ID: <DB1zsE.77I@world.std.com>
Organization: The World Public Access UNIX, Brookline, MA
References: <NEWTNews.804269222.4596.sellers@sellers.sellers.com> <1995Jun30.212050.26112@merlin.hgc.edu> <DB0IGA.1Cq@world.std.com> <3t3mtb$i5@mail.one.net>
Date: Sat, 1 Jul 1995 20:05:02 GMT
Lines: 112
Xref: glinda.oz.cs.cmu.edu comp.object:34108 comp.lang.smalltalk:25324 comp.lang.ada:31984 comp.lang.c++:136196

In article <3t3mtb$i5@mail.one.net>,  <oconnor@basenet.net> wrote:
>	Ada95 now supports of form of single-inheritance through the use of
> tagged records.  I'll put my cards on the table now and say, though, that
> Ada95 is still not an OO language.

Well, the term "object oriented" has come to mean "good", so I expect
this to devolve into a flame war -- I'm sure there are Ada advocates who
will take your claim that Ada 95 is not OO as a greivous insult.  ;-)

I don't, but I do claim that Ada 95 supports OOP, and can reasonably be
called an "object-oriented language".

You seem to be saying that Ada 95 is not OO because the behavior of an
object is not part of the object.  Well, that's not quite true.  It is
true that the operations of a given object are not considered to be
"inside" the object, as they are in most OO languages.  So you don't use
the prefix notation (as in "object.operation") to invoke an operation of
an object.  Some people think that makes it non-OO.  You can, of course,
define OO however you want.  Bertrand Meyer, for example, has stated
that OO requires garbage collection -- so by his definition, C++ is not
an OO language.  (That has always seemed like a confusion to me -- it's
more useful to argue about whether garbage collection is a good idea,
rather than whether garbage collection is part of the definition of OO.
If you use the term OO for anything you think is a good idea, the term
loses its usefulness.)

OO requires inheritance, polymorphism, and encapsulation.  Ada 95
supports all of those.  (Ada 83 only supported the last.)  The
difference between Ada 95 and other OO languages like C++ and Smalltalk,
is that the encapsulation support is separated from the support for
inheritance/polymorphism -- the package supports encapsulation, with
information hiding; the tagged type, with record extensions and
dispatching operations, supports inheritance and polymorphism.  There
are some advantages to this separation -- not huge benefits, but you can
do some things in a more elegant manner.  To me, the main difference
between the Ada style and the C++ style is a minor syntactic difference;
conceptually, the basic capabilities are the same.

Ada is not the first OO language to make this separation.  For example,
the Common Lisp Object System does not view the operations of an object
as being inside the object, and does not use the prefix notation of C++
or Smalltalk.  Most people, I think, consider CLOS to be
object-oriented.  (In fact it's about the most powerful object-oriented
system I can imagine!)

Despite the fact that the operations of an Ada object are not considered
part of the object, they are closely associated with the object.  You
declare a tagged type, typically in a package, together with some
associated operations.  These operations that are declared together with
the type are called "primitive operations" of the type.  When you create
an object of the type, the object has an associated Tag, which allows
the object to remember that type.  Later, when you call a primitive
operation of on the object, it will dispatch to the right one, according
to the Tag -- this is just like every other OO language -- the object
knows (at run time) what behaviors it supports, and the right operation
is invoked accordingly.

So, if your definition of OO disqualifies Ada 95 (and CLOS and others),
that's fine -- people have lots of different definitions of OO, and
people can define terms however they want.  It seems a bit silly to me,
though, because all the useful OO capabilities are there.  If it
provides the benefits of OO, then why not call it OO?

> ...  Dynamic binding and extendable records
> do not an object make.  The simple reason it is not OO is that there are no
> objects.  Declaring a variable to be off a particular data-type (record) does not 
>make it an object.  It's existance does not endow it with any functionality.  
>It just allocates memory for data.  All the functionality for the object is defined 
>in the package that defines the record.  However the package is not an object, 
> its  really more of an organizational ans scoping tool for the compiler (similar
> to C++ name space).  There is nothing that says that if a particular package
> defines a private record (defining the data for an 'object'), that the procedures 
>and functions within that package have any connection to the exported record.

The run-time Tag of the object associates an object with its primitive
operations -- the ones defined in the same package as the type.  The
package encapsulates the type and its primitive operations.  It is true
that you can put random unrelated junk in there, but that's true in any
language.  Even in Smalltalk, which is about the purest form of OO there
is, you can define a method in a class that has nothing to do with it.
No language can *force* OO -- an OO language is one that *supports* it.

>  Any run-time correlation between the data and the functionality is purely
> up to the client of the package.  Even allowing this in the first place is still
> up to the builder of the package.
>
>	I realize that in C++  you can build a poorly defined class that seems to
> have a weak correlation between it's data and functionality, but at least you have
> to declare a variable to be of a class and reference that class to get to any 
>functionality (the exception being static members).  You can actually point
> to something and say...'That's an object'.  
>	In Ada95, you can't do that.  The variable isn't an object; it's a 
>record, at best. It's existance endows it with no behavior.  The 
>package isn't an object; it has no run-time existance, but it CAN be used 
> to provides behavior for the declared types.

I agree that a package is not an object.

>	I can understand the idea of a multi-paradigm language; C++ is 
>one such.  However, I've heard Ada95 being touted as an OO language
> rather loudly and that's simply not true.  It enables OO programming
> better than Ada83 did, but that does not make it an 'OO' language.  Per
> example,  the GeoWorks environment, I heard, was written in Assembly
> Language using OO, but I've never heard any claim the Assembly was
> an OO language.

Agreed -- to be called an OO language, the language ought to provide
some direct support for the basic concepts of OO.  But the syntactic
sugar used to actually attach operations and objects together seems
irrelevant to me.

- Bob
