Re: Definition of Buzzwords: "Object-Oriented"

Re: Definition of Buzzwords: "Object-Oriented"

[Ian Kaplan]

In article <366@cavell.UUCP> brian@cavell.UUCP (Brian Wilkerson) writes:
>
>I therefore propose that the original definition be revised to read :
>
>object-oriented, adj., 1. wholly or largely concerned with the definition
>   and use of abstract data types. 2. consisting wholly or largely of
>   abstract data types.
>
>Brian Wilkerson
>   ...!ihnp4!alberta!brian


  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.  A Modula definition module defining such a stack "object" 
  is shown below.  The actual stack data structure is hidden inside the 
  module.  It can only be manipulated by the two procedures Push and Pop.

      DEFINITION MODULE StackOps;  
      FROM ExpTypes IMPORT Operators;
      EXPORT QUALIFIED Push, Pop;
      
        PROCEDURE Push( Value : REAL );
      
        PROCEDURE Pop() : REAL;
        
      END StackOps.

  In Modula there would also be a separately compiled implementation module
  which would implement the data structure and the procedures Push and Pop.
  This module is not important for this discussion.

  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++.  These languages support abstract data types.  To add 
  this facility to Modula, one would have to be able to declare a variable 
  whose type was the object.  For example:

    VAR 
      MyStack : StackOps.

  Operations on the object would be performed in the following way

     Value := MyStack.Pop;

	   and

     MyStack.Push( Value );

   In this case the operations are explicitly associated with the data
   type, it is not a loose associate as is the case with a Modula module.
   Concurrant Pascal uses a scheme similar to the one I have outlined[2].

   This is a rather long winded way of stating that I agree with Brian 
   Wilkerson's definition of an object oriented language.  An object
   oriented language provides an abstract data type which embodies both 
   the data and the operations which can be performed on the data.  
   Although there are clearly similarities between this and the facilities
   provided by Modula and Ada, these languages are not truly object 
   oriented languages.

  [1] "Software Engineering With Modula-2 and Ada" by Wiener and Sincovec,
      John Wiley and Sons, 1984
  [2] "The Architecture of Concurrent Programs" by Per Brinch Hansen,
      Prentice-Hall, 1977

			     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

Re: Definition of Buzzwords: "Object-Oriented"

[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... "

Re: Definition of Buzzwords: "Object-Oriented"

[Ian Kaplan]

In article <247@cheviot.UUCP> robert@cheviot.UUCP (Robert Stroud) writes:
>
>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.
>
    ... more discussion regarding packaging in Ada etc....

>Is it possible to focus on that difference and produce
>a definition of "object-oriented" that *excludes* Modula-2??
>
>Robert Stroud,
>Computing Laboratory,
>University of Newcastle upon Tyne.
>
>ARPA robert%cheviot%newcastle.mailnet@mit-multics.arpa
>UUCP ...!ukc!cheviot!robert
>

  The point that I was trying to make in my Concurrent Pascal example was
  that there should be a strong association between the data structure and
  the operations that can be perfored on it.  I think that Robert Stroud is
  probably right when he states that the differences between my Concurrent
  Pascal example and the way the same thing is done in Modula is syntatic
  sugar.  
  
  After I wrote my article several other people pointed out that
  the real difference between Modula (or Ada) and an object oriented 
  language like Smalltalk or C++ is inheritance.  Inheritance allows new
  abstract data types to be formed from the "properties" of other abstract
  data types.  In a way, inheritance does for abstract data types what user
  defined data types does for elementary data types in Modula.

  When discussion the differences between a "truely" object oriented
  language and Modula with a friend, my friend pointed out that you must
  make a distinction between what you can simulate in a language and the
  properties of the language.  For example, a programmer can simulate
  recursion in FORTRAN by using an array like a stack, but recursion is not
  one of the features of FORTRAN.  There is clearly some overlap between the 
  object oriented languages and Modula or Ada.  Despite this overlap, they 
  really are different languages.  
  
  I think that the problems we are all having in defining the 
  differences between object oreinted languages and Modula is that
  until recently (when the mini-Smalltalk implementation became available)
  object oriented languages were not generally available.  I believe that
  if we were to use object oriented languages, rather than just read
  about them, the difference would be much more apparent.

  By the way, from what I understand AT&T has no plans to release C++.  If
  this is true, I think that it is a real loss to the computer science
  community.

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

Re: Definition of Buzzwords: "Object-Oriented" (really C++)

[Arnold Robbins]

In article <777@loral.UUCP> ian@loral.UUCP (Ian Kaplan) writes
>   By the way, from what I understand AT&T has no plans to release C++.  If
>   this is true, I think that it is a real loss to the computer science
>   community.

This is getting off the topic a little bit, but I wanted to clear a point
up.  AT&T is releasing C++ *only* to educational licensees.  The cost is
$150 for the tape and another $20 for the printed documentation.

I would love to see C++ released to everyone, but at least some people can
get hold of it.  The fact that they are releasing it at all encourages me
to hope that eventually everyone will be able to get it.
-- 
Arnold Robbins
CSNET:	arnold@gatech	ARPA:	arnold%gatech.csnet@csnet-relay.arpa
UUCP:	{ akgua, allegra, hplabs, ihnp4, seismo, ut-sally }!gatech!arnold

Help advance the state of Computer Science: Nuke a PR1ME today!

Re: Definition of Buzzwords: "Object-Oriented"

[Juha I. Heinanen]

I agree with Robert Stroud that from the programmer's point of view it
was a serious mistake to include the privite part in the package
specification and thus force the programmer to tell the memory
representation of a private type before writing the package body.  Since
the algorithms depend on memory representation and vice versa it is in
practice impossible to separate the specification from the
implementation.  This ruins the whole idea of data abstraction with
separate compilation.  

What comes to Modula-2, I wouldn't have placed any restrictions on the
memory representation of opaque types.  If the actual representation
turns out to fit in one word then that is fine.  If not I would have
made the compiler implicitly declare a pointer variable that points to
the real memory representation and implicitly allocate the object from
the heap.  Similarly all direct references to the memory representation
would have been implicitly changed to pointer references.  This
arrangement would have freed the programmer from the artificial
introduction of pointer variables.

                                 Juha Heinanen

USL, P.O. Box 44330, Lafayette, LA 70504,  tel. (318)231-5345
UUCP:  {ut-sally, akgua}!usl!jih      ARPA:  usl!jih@ut-sally

-- 
Will this be appended?

Re: Definition of Buzzwords: "Object-Oriented"

[Dick O Schefstr|m]

  The not too fruitful discussion of whether Ada or Modula-2 is more 
"object-oriented" seems to turn into a discussion of implementation
of "private" or "opaque" types. 

  Maybe typical to Ada, it provides
several ways of doing things: the Modula-2 style of private types
is in Ada achieved by in the private part declaring an "access" type,
allowing us to defer the layout of the structure pointed to until
writing the implementation part. This give us a higher degree of
independency between specification and implementation parts, but it
also means that we cannot give default initializations to private
types and an initialization routine must be explicitly called.
  If you create a lot of temporary used objects of this private type,
using the "pointer style", you might have to start thinking about
reuse of space and garbage collection. To statically allocate objects
has drawbacks, but their space is easily and automatically reclaimed 
when no longer used by the simple procedure call-stack mechanism. 

Dick Schefstrom, 
Computer Science Department
University of Lulea
S-951 87 Lulea
Sweden