Xref: utzoo comp.lang.c++:3094 comp.lang.misc:2852 comp.lang.smalltalk:1010 comp.lang.lisp:1686 comp.lang.modula2:1447
Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!ames!lll-lcc!lll-winken!uunet!pdn!rnms1!alan
From: alan@rnms1.paradyne.com (Alan Lovejoy)
Newsgroups: comp.lang.c++,comp.lang.misc,comp.lang.smalltalk,comp.lang.lisp,comp.lang.modula2
Subject: Re: C++ and other OOP Languages
Keywords: C++, OOPS
Message-ID: <5971@pdn.paradyne.com>
Date: 22 Apr 89 17:49:56 GMT
References: <823@ethz.UUCP>
Sender: news@pdn.paradyne.com
Reply-To: alan@rnms1.paradyne.com (Alan Lovejoy)
Organization: AT&T Paradyne, Largo, Florida
Lines: 70

In article <823@ethz.UUCP> marti@ethz.UUCP (Robert Marti) writes:
>Some previous articles discussed the "object-orientedness" (what a
>word!) of C++, Objective C and various other languages.  Let me add
>me 2 cents worth, even though I usually regret posting my opinions
>to USENET afterwards ... :-)

Hey, if nobody ever posted controversial articles, usetNET would be useLESS!
So don't be shy.

>Today, most people can probably live with the following "definiton":
>(We'll soon hear from those who can't :-)
>
>A language is OO if
>1) it supports data encapsulation (information hiding, abstract data types),

It must have classes.  A class can be instantiated.  Data encapsulation is 
just a synonym for information hiding.  Sine you mention abstract data types 
in your definition, however, you get at least 1/2 credit.  A class might be 
operationally defined as an abstract data type with information hiding, since a
data type is instantiable. But many will argue that it still isn't a class 
unless it also has inheritance and a set of functions bound to instances of the
class (messages).  If abstract data type implies all this, or at least implies a
set of bound functions, then the distinction between a class and an abstract 
data type begins to be rather "academic" (differing at most by +/- inheritance).

So what's the difference between a class and an abstract data type? Comments?

>2) it supports inheritance (subclassing, extensible record types, ... )
>   and

Extensibilty is NOT the same thing as inheritance.  Inheritance permits
the definition of a new class in terms of the differences between the new
class and the superclass.  An extension is only one type of difference.
There are also changes in the structure or function of inherited
characteristics and simple removal of inherited characteristics.

Inheritance can be thought of as "polyparameterization"--to coin a new term.
If a class were a parameterized abstraction (a "generic package" in Adaspeak)
where every characteristic were parameterized, then instantiating instances
of the class abstraction with different parameter sets would achieve the
same effects as can be obtained using inheritance.  That is why Smalltalkers
sometimes refer to classes that were designed to be inherited as "abstract
classes."  Each subclass does what amounts to parameter substitution by
overriding the inherited methods.

>3) it supports determination of the procedure body to be executed at the
>   time of the actual procedure call (message passing, virtual functions).

Your language is ambiguous.  "At the time of the actual procedure call" could
mean either at run time or at compile time.  If only at compile time, then
this is the same thing as overloading.   If also at run time, then it is
dynamic message-to-method binding.  Your parenthetical comment indicates
you are referring to dynamic method binding (for which overloading is a
prerequisite).

I agree. In an earlier posting I listed overloading as a requirement, but
not dynamic method binding.  That was an oversight, which your posting made
me aware of.  I *knew* better, too.  Arghhhh!!  I was thinking about
polymorphism at the time.  With full polymorphism, one must have dynamic
method binding (the value of a reference--such as a function address--must be
a computable value).

My list also included polymorphism, but the purpose of the list was to define
the ideal OO language.  Your list (as I have ammended it) is probably close
to what the consensus would be for the minimum requirements.

Alan Lovejoy; alan@pdn; 813-530-2211; AT&T Paradyne: 8550 Ulmerton, Largo, FL.
Disclaimer: I do not speak for AT&T Paradyne.  They do not speak for me. 
_________________________Design Flaws Travel In Herds_________________________
Motto: If nanomachines will be able to reconstruct you, YOU AREN'T DEAD YET.