[comp.lang.c++] C++ and other OOP Languages

marti@ethz.UUCP (Robert Marti) (04/20/89)

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

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),
2) it supports inheritance (subclassing, extensible record types, ... )
   and
3) it supports determination of the procedure body to be executed at the
   time of the actual procedure call (message passing, virtual functions).

Using this definiton, C++, Objective-C, Smalltalk, Lisp+CLOS, Eiffel,
Modula-3, and Object-Pascal are all OO, since they fulfill all of the
above criteria.  Oberon only supports (1) and (2) directly, and is not
fully OO as a result.  Modula-2 and Ada (TM of somebody or other) only
support (1) and are definitely not OO.

-- 
Robert Marti                      Phone:      +41 1 256 52 36
Institut fur Informationssysteme
ETH-Zentrum                       CSNET/ARPA: marti%inf.ethz.ch@relay.cs.net
CH-8092 Zurich, Switzerland       UUCP:       ...uunet!mcvax!ethz!marti

alan@rnms1.paradyne.com (Alan Lovejoy) (04/23/89)

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.

marti@ethz.UUCP (Robert Marti) (04/26/89)

In article <5971@pdn.paradyne.com>, alan@rnms1.paradyne.com (Alan Lovejoy)
writes:
| In article <823@ethz.UUCP> marti@ethz.UUCP (Robert Marti) writes:
| >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.

Thanks for the 1/2 credit :-)   At any rate, class instantiation is
not all that important to me, since it can be "simulated" in a
straightforward manner within more conventional languages.  I do
agree that it's a nice feature to have, though.

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

Same difference as far as I am concerned.

| >[ A language is OO if ]
| >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.

Agreed.  Ideally you'd want to extend, restrict and override definitions
inherited from a superclass.

| >[ A language is OO if ]
| >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.

I meant at run time, of course.

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

More violent agreement here :-)

| Alan Lovejoy; alan@pdn; 813-530-2211; AT&T Paradyne: 8550 Ulmerton, Largo, FL.

-- 
Robert Marti                      Phone:      +41 1 256 52 36
Institut fur Informationssysteme
ETH-Zentrum                       CSNET/ARPA: marti%inf.ethz.ch@relay.cs.net
CH-8092 Zurich, Switzerland       UUCP:       ...uunet!mcvax!ethz!marti

new@udel.EDU (Darren New) (04/29/89)

In article <832@ethz.UUCP> marti@ethz.UUCP (Robert Marti) writes:
>In article <5971@pdn.paradyne.com>, alan@rnms1.paradyne.com (Alan Lovejoy)
>writes:
>| So what's the difference between a class and an abstract data type?
>| Comments?
>
>Same difference as far as I am concerned.

My understanding of the difference between classes and ADTs is that
class instances have states whereas ADT `instances' are expressions.
In other words, it is similar to the difference between
procedural languages (classes) and functional languages (ADTs).
		-- Darren