Re: Definition of Buzzwords: "Object-Oriented"

[robert@cheviot.UUCP (Robert Stroud)]

In article <769@loral.UUCP> ian@loral.UUCP (Ian Kaplan) writes:
>
>  Several books have come out which suggest that languages like Ada and
>  Modula-2 are "object oriented" languages[1].  These languages are object
>  oriented in that a module (or package) can be defined which contains a
>  data structure and the operations which can be performed on the data 
>  structure.
>
>  ... example of MODULE containing a STACK abstraction
>
>  There is a real difference between the type of "object" which can be
>  created using Modula's modules and the objects in a language like
>  Smalltalk or C++.  
>
>  .... discussion of how one *might* declare ADT's in Modula-2
>

But it *is* possible to define abstract types in Modula-2, (or Ada - hiss!).

Modula-2 lets you export a TYPE name without defining the TYPE structure -
this is called "opaque export" and is discussed under "14. Compilation Units"
in my version of the Modula-2 Report.

You can then declare variables of this type, but the only way you can use
them is as parameters to procedures or functions exported by the MODULE
which defines the TYPE - where the internal structure is known. So if
we have a MODULE StackDef which EXPORT's the TYPE Stack and procedures
Push and Pop, we can write....

	FROM StackDef IMPORT Stack, Push, Pop;

	VAR
	  S : Stack;

	BEGIN
	   ...
	   Push(S, ...);
	   Pop(S, ...);
	   ...
	END;

You even have to call an exported procedure (not shown) to initialise
the Stack before you use it - unlike Ada, Modula-2 does not allow
initialisation at declaration.

This is *not* the same as Concurrent Pascal notation, 

	S.Push(...); S.Pop(...);

but the difference is really just philosophical - does the operation
belong to the object or vice-versa. Some would say that this makes
a language "object-oriented" rather than "procedure-oriented" although
the distinction is purely syntactic sugar.

In "Chapter 25 Program decomposition into modules" of Wirth's book
on Modula-2, he says that MODULE's come in three flavours. They can
map between two data types, encapsulate a single data type or implement
a data type in the way I have described. The MODULE's in Modula-2 have
more to do with visibility, lifetime and scope than data types.

The corresponding mechanism in Ada is

	type Stack is private;

However, there is one (to my mind) crucial difference. In Modula-2
there is *nothing* about the TYPE definition in the DEFINITION MODULE
*anywhere*. However, since the compiler must be able to allocate space
for an opaque object, the size is fixed, (specifically the TYPE must
be a POINTER or a subrange of a standard type, i.e. one "word").
In practice, this is not a problem - the "real" type is a massive
RECORD, and the opaque type is a pointer to the RECORD; the create
operation allocates space for the object and initialises its value.

In Ada however, (flame flame), the package interface (to use Ada terminology)
contains a private part which spells out the type definition and initial
value as appropriate. This means that the compiler knows the information
even it denies the knowledge to the programmer.

So what you ask? Well, consider what happens when you decide you want
to change the internal representation of your abstract type. In Modula-2
you just have to compile the IMPLEMENTATION part of the module; in Ada
you have to re-compile the interface. That means you have to re-compile
*everything* that uses that interface (and some other interfaces may
use the interface...). Anyone who has had experience of writing large
programs in languages with strong-type checking across compilation 
boundaries (e.g. Modula-2 or Mesa) will tell you that re-compiling 
interfaces is *bad* news!!

Personally, I wonder if a clever linker could solve this problem,
lifting the restriction in Modula-2 and banishing the private part
of the interface from Ada. However, in the meantime I prefer the
Modula-2 solution.

An object-oriented language like Smalltalk or C++ (I guess), gets
round this difficulty by allocating all objects off the heap dynamically
at run-time, and referring to everything indirectly with pointers.
Smalltalk even goes as far as to do all its type checking and binding
of operations to implementations at run-time, which adds a substantial
run-time overhead. On the other hand, it makes the conventional compile/link
cycle unnecessary, making it very fast to prototype applications.

Although you can program Abstract Data Types in both Modula-2 and Smalltalk
(making them both "object-oriented"??), there is a big difference between
the two languages. Is it possible to focus on that difference and produce
a definition of "object-oriented" that *excludes* Modula-2??

>			     Ian Kaplan
>			     Loral Data Flow Group
>			     Loral Instrumentation
>		     USENET: {ucbvax,ihnp4}!sdcsvax!sdcc6!loral!ian
>		     ARPA:   sdcc6!loral!ian@UCSD
>		     USPS:   8401 Aero Dr., San Diego, CA 92123
>                             (619) 560-5888 x4812

Robert Stroud,
Computing Laboratory,
University of Newcastle upon Tyne.

ARPA robert%cheviot%newcastle.mailnet@mit-multics.arpa
UUCP ...!ukc!cheviot!robert

"... you can solve any problem in Computer Science by adding an extra
 level of indirection... "