[net.lang.st80] Definition of Buzzwords: "Object-Oriented"

wildbill@ucbvax.ARPA (William J. Laubenheimer) (01/22/85)

I have recently been involved in some discussions in which the topic
of so-called "object-oriented" languages and programming techniques
has been explored. Despite the fact that "everybody knows" that
Smalltalk-80 is "object-oriented" and "everybody knows" (or pretends
that they do) what "object-oriented programming" is, this same
group of "everybody"s is having a hard time coming up with a rigorous
definition of those terms which goes beyond one of the two following:

1) The term is self-explanatory: the orientation of the language/program
   is towards the "object". This causes the discussion to move in
   the direction of defining an "object", and how exactly the language
   or program is oriented in that direction.

2) The term is defined by example: if somebody says a language is "object-
   oriented" and most people agree, then the language is object-oriented
   (the "science fiction" definition approach - "science fiction" is what
   "science fiction authors" write, "science fiction editors" buy, and
   "science fiction fans" read).

Neither of these approaches makes anybody particularly happy. Nobody's
been able to find an accepted definition in the literature, either.
So, the question is:

Is there a definition of the term "object-oriented" which is both descriptive
of all current uses of that term and accepted by all who currently use it?
If not, can such a definition be constructed?

I would be interested in hearing from anybody who has any ideas relating
to this topic.

                                        Bill Laubenheimer
----------------------------------------UC-Berkeley Computer Science
     ...Killjoy went that-a-way--->     ucbvax!wildbill

macrakis@harvard.ARPA (Stavros Macrakis) (01/23/85)

> Is there a definition of the term "object-oriented" which is both descriptive
> of all current uses of that term and accepted by all who currently use it?
>                                         Bill Laubenheimer ucbvax!wildbill

`Accepted by all who currently use it' is harder than `descriptive'....

Let me propose:

  An object-oriented language/system considers its behavior to be
  defined in terms of the behavior of smaller units (called
  `objects') each of which has a repertoire of operations
  applicable to it.  The object operations are the only operations
  which normally have access to the underlying implementation of
  the object.  Almost all object-oriented systems organize objects
  into classes of different individual objects which share the
  same repertoire of operations, and these classes can normally
  have subclasses which inherit the operations of the classes and
  add more classes.  Almost all object-oriented systems allow (and
  encourage) objects to have internal state which changes with time.

This definition emphasizes the differences with other language
qualities, such as `algorithmic' (Algol, Fortran, Pascal, C, Snobol,
APL), `functional' (Lisp, FP, APL), `backtracking' (Snobol, Planner,
Prolog), or `string-oriented' (Snobol, Trac, Teco); but note that the
qualities are not exclusive.  Too often, spurious questions on the
order of `is it algorithmic or is it object-oriented' cloud the
question.  A serious question, however, is whether changing state is
important to object orientation.  Perhaps this is the difference
between data abstraction and object orientation?  Or is object
orientation just the fashionable name for data abstraction?

A more historically-oriented definition might be:

  Object-oriented languages/systems are inspired by Simula 67.

Note that it is not important to these definitions whether the
language is part of an interpretive system (like Smalltalk), nor is
the inheritance mechanism central (of course you can argue that a GOOD
object-oriented system has a certain kind of inheritance mechanism).

By these definitions, Simula 67, CLU, Smalltalk, Objective C, Ada, and
ZetaLisp are all object oriented.  They do differ.  Some enforce the
access restrictions of the class, others don't; some have
sophisticated (or just plain complicated) inheritance mechanisms,
others don't.

But I think it would be unfair to frame a definition which excluded
any of these languages.

	-s

brian@cavell.UUCP (Brian Wilkerson) (01/23/85)

> Is there a definition of the term "object-oriented" which is both descriptive
> of all current uses of that term and accepted by all who currently use it?
> If not, can such a definition be constructed?

I don't know of any "standard" definition for the term "object-oriented",
but I will attempt to construct one. Whether or not it will be widely accepted
is something we should find out when people start replying to this article.
One alternative you suggested was the following.

> 1) The term is self-explanatory: the orientation of the language/program
>    is towards the "object". This causes the discussion to move in
>    the direction of defining an "object", and how exactly the language
>    or program is oriented in that direction.

I define "object" as follows :

object, n., 1. a member of an abstract data type.

This definition undoubtedly stems from my familiarity with Smalltalk-80.
(The correspondence between abstract data types and classes is relatively
clear.) It does, however, seem to be consistent with other uses of the
word which I have seen.

This leaves only the problem of how the language, program or programming
methodology is oriented towards the object. It seems to me that people,
when they say that Smalltalk is object-oriented, mean that Smalltalk is
a language in which everything is an object. This may be a bit too
restrictive to be useful, though.

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

jjm@petsd.UUCP (Jim Moseman) (01/23/85)

I use "object-oriented" to describe a design strategy with the following
characteristics:

   1. The programs's objective is described in terms of one or more higher
level entities (objects).  For example, an algorithm involving a depth first
search of a tree is easier to describe in terms of a stack and its push and
pop operations than in terms of lower level entities such as arrays and
indices.

   2. The implementation of the object and its operations (its representation
and the algorithms which manipulate it) is isolated from the implementation
of other objects and from the algorithms which use the object.  This allows
a 'divide and conquer' approach and simplifies maintenance by limiting the
effect of changes.
 
Jim Moseman @ Perkin-Elmer, Tinton Falls, N.J.
.../vax135/petsd/jjm

jans@mako.UUCP (Jan Steinman) (01/23/85)

<4288@ucbvax.ARPA> wildbill@ucbvax.ARPA (William J. Laubenheimer) writes:
>I have recently been involved in some discussions in which the topic
>of so-called "object-oriented" languages and programming techniques
>has been explored... (we are) having a hard time coming up with a rigorous
>definition of those terms...
>
>1) The term is self-explanatory: the orientation of the language/program
>   is towards the "object". This causes the discussion to move in
>   the direction of defining an "object", and how exactly the language
>   or program is oriented in that direction.

I essentially agree with this argument, but see no problem providing a
rigorous definition of an "object", which is, most generally, a cohesive
collection of data and allowed operations on that data.  Within an object
data-function binding is high, while between objects, a loose coupling
mechanism is used to protect the integrity of those objects.

"An object consists of some private memory and a set of operations...  Objects
 representing numbers compute arithmetic functions.  Objects representing data
 structures store and retrieve information." [1:p6]

The crucial point is the collection of data AND functionality.  Traditional
languages keep the two apart and allow functionality to operate ON data.
Object oriented languages have objects knowledgeable in the kinds of things
they may do to their data -- these objects honor requests from other objects
to do these things.  The net effect is one of greater modularity, reliability,
(because an object will not permit its data to be corrupted by inappropriate
operations) and generally better understandability, due to the intuitive
face objects present.

"...modules may be functional (procedure-oriented) or declaritive (object-
 oriented)... we want modules that exihibit strong cohesion..." [2:p29]

"A crucial property of an object is that its private memory can be manipulated
 only by its own operations." [1:p6]

The second major indicator of "objectness" is the degree of modularity.  Some
try to argue that "C" is modular, simply because functions and data can be
seperately compiled, but the language does not enforce any sort of binding
within such modules!  True objects will have tight binding, or cohesion,
within a module, and loose coupling between other modules.  This binding must
extend to the binding between data and functionality, as stated in my first
point.  To sum up this too long answer:

"We shall call this an *object-oriented* design methodology to emphasize the
 fact that it is not a purely functional design technique.  Instead, this
 approach recognizes the importance of software objects as actors, each with
 its own set of applicable operations." [2:p40]

References:
[1] "Smalltalk-80, The Language and its Implementation", Adele Goldberg, David
	Robson
[2] "Software Engineering With Ada", Grady Booch (excellent book!)
-- 
:::::: Jan Steinman		Box 1000, MS 61-161	(w)503/685-2843 ::::::
:::::: tektronix!tekecs!jans	Wilsonville, OR 97070	(h)503/657-7703 ::::::

jeh@ritcv.UUCP (Jim Heliotis) (01/23/85)

> Is there a definition of the term "object-oriented" which is both descriptive
> of all current uses of that term and accepted by all who currently use it?
> If not, can such a definition be constructed?
> 
>                                         Bill Laubenheimer

If you would like to test every language for object-orientedness, and answer
'yes' or 'no', then I'd say that is the wrong approach.  I would rather say
things like (1) Pascal is not very object-oriented, (2) Ada is rather o-o,
and (3) Smalltalk-80 is very o-o, because even booleans are defined as ST80
objects.

I realize I am not offering a definition.  I just want to point out that I think
it is a matter of degree.

				Jim Heliotis
				{allegra,seismo}!rochester!ritcv!jeh
				rocksvax!ritcv!jeh
				ritcv!jeh@Rochester

ekrell@ucla-cs.UUCP (01/24/85)

In article <4288@ucbvax.ARPA> wildbill@ucbvax.ARPA (William J. Laubenheimer) writes:
>Is there a definition of the term "object-oriented" which is both descriptive
>of all current uses of that term and accepted by all who currently use it?
>If not, can such a definition be constructed?
>
>I would be interested in hearing from anybody who has any ideas relating
>to this topic.

  I read this somewhere: a procedure-oriented language represents the
behavior of a program by describing the effect of applying procedures
to different kinds of arguments (here procedures being a broad term
including assignments, arithmetic operators, etc).
  An object-oriented language does it by describing the effect of applying
different procedures (methods) to a specific object.

  I like this (informal) definition because it captures the radical difference
between procedure and object-oriented languages.
-- 
    Eduardo Krell               UCLA Computer Science Department
    ekrell@ucla-locus.arpa      ..!{sdcrdcf,ihnp4,trwspp,ucbvax}!ucla-cs!ekrell

koved@tove.UUCP (Larry Koved) (01/25/85)

A rather good description of what it means to be "object-oriented"
was given in a paper by Curry and Ayers, entitled "Experience with
Traits in the Xerox Star Workstation", IEEE TSE, Sept 1984.

It is the best description that I have seen so far, although not
totally satisfactory.

Larry

-- 
Spoken: Larry Koved
Arpa:   koved.umcp-cs@CSNet-relay
Uucp:...{allegra,seismo}!umcp-cs!koved

robert@cheviot.UUCP (Robert Stroud) (01/25/85)

Bill Laubenheimer (wildbill@ucbvax.arpa) asks for a definition of 
object-oriented programming.

I have always been fond of the following quotation...

    "Object-oriented programming will be in the 1980's
     what structured programming was in the 1970's.
     Everyone will be in favour of it...
     Every programmer will practice it (differently).
     And no one will know just what it is!"

It comes from an article entitled "Object-Oriented Programming" by
Tim Rentsch which can be found in ACM SIGPLAN Notices, September 1982
on pages 51 to 57. The article goes on to try and characterise just
what object-oriented programming is all about, and I recommend you
look it up if you're interested.

Personally, I remain to be convinced that there is any fundamental
difference between objects/messages and abstract data types/operations,
but I guess that is just swapping one bit of jargon for another!

However, I do agree with previous correspondents that it is a matter
of degree rather than an absolute measure, although I would put more
weight on the importance of the class hierarchy, inheritance and
polymorphic aspects of an object-oriented programming language.

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

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

"It ain't what you do, it's the way that you do it"

glassner@unc.UUCP (Andrew S. Glassner) (01/25/85)

The posting on OO buzzwords asked for definitions of the term "object-
oriented".  To me, the words describe a point of view and a style of
implementation.

The point of view is that the procedure/data relationship is flipped
over from that of most other languages, e.g. Algol, APL, Snobol, etc.
Thus, instead of having a general procedure "cut" that accepts the
two pieces of data "scissors" and "paper", we have an object "scissors"
that is given "paper" and told to "cut".  

The meaningful thing for me in this view is that relationships between
objects (data in the Algol view) are *implicit*, not explicit.  If a
balloon object is told that air is arriving at the hole, it will blow
itself up.  It doesn't need to know from where that air arrives, and
the balloon does not need to be told in its code of all the different
places from which air can arrive.

The style of implementation of object-oriented code is that of self-contained,
encapsulated "objects" (or collections of procedures, or "methods")
that communicate with each other via "messages", or commands.  This
takes the popular notion of "hiding" important information or local
data to a fully-implemented conclusion.  Each object is responsible
for its own local information (the data which describe it and the
messages to which it can respond), and nobody else can touch that
information.  Other objects may ask to see it or ask to change it,
but only the owner of the information has direct access to it.

In my perception, the difficulty in defining the term object-oriented
rests in a subtle point of view.  In general, when one is learning
of a new idea (or having a new idea defined), a major question is
"Why am I being told this?"  The usual expectation is that the new
concepts or techniques are somehow *better* than other techniques,
and indeed this is the usual reason people try to expose us to
other ways of doing things.  

To compter-science people, "better" often means "more powerful",
or "more expressive".  Thus, APL is "better" than ALGOL because
it can express complicated ideas in compact space, whereas ALGOL
is "better" than APL because it is more readable.  The problem
is that the object-oriented point of view, when described statically,
appears no more "powerful" than the traditional procedure/data
model.  Thus, why bother to spend the time and energy to learn it?

I feel the justification comes from the point of view that the
programming model we work with profoundly affects our work.  This
isn't a new idea; the example is often made that the spoken language
you use affects the way you think and approach problems.  So
although the "object/method" view may not immediately seem more
"powerful" than the "data/procudure" view, it is a different way
to describe the work to be done.  If the new point of view is
as powerful as the old (which it is), and if it is truly a new
point of view (which can be argued, but only after one understands
it!), then that is justification in itself for its study.  

To my mind, the OO point of view is "better" because it lets me formulate
my problems in terms of implicit relationships between intelligent data,
rather than explicit manipulations of information.  I suggest that
the above may also serve as a defintion of "object-oriented".

-- 

-Andrew		Andrew Glassner		decvax!mcnc!unc!glassner

ian@loral.UUCP (Ian Kaplan) (01/25/85)

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

robert@gitpyr.UUCP (Robert Viduya) (01/27/85)

>< 
>   I read this somewhere: a procedure-oriented language represents the
> behavior of a program by describing the effect of applying procedures
> to different kinds of arguments (here procedures being a broad term
> including assignments, arithmetic operators, etc).
>   An object-oriented language does it by describing the effect of applying
> different procedures (methods) to a specific object.
> 

The definition is lacking two important things:  the definition of 'arguments'
and the definition of 'objects'.  After all, an argument could, in some contexts
be considered an object.

				robert
-- 
Robert Viduya
    Office of Computing Services
    Georgia Institute of Technology, Atlanta GA 30332
    Phone:  (404) 894-4669

...!{akgua,allegra,amd,hplabs,ihnp4,masscomp,ut-ngp}!gatech!gitpyr!robert
...!{rlgvax,sb1,uf-cgrl,unmvax,ut-sally}!gatech!gitpyr!robert

trow@uw-june (Jay Trow) (01/27/85)

Forwarded from Smalltalk80Interest^.x@Xerox.arpa

----------------------------------------------------------------

Date: 23 Jan 85 08:58:44 PST (Wednesday)
From: Cornish.SV
Subject: Re: Definition of Buzzwords: "Object-Oriented"

This is not going to be a "rigorous definition".  First, let's realize,
that to say a software system is "object oriented" really means that the
architecture of a software system is "object oriented".

Now just what does the term "architecture of a software system" really
mean?  Any software system has a purpose.  The architecture of a software
system must be devoted to achieving that purpose, just as the architecture
of a building must be devoted to achieving the purpose of that building.

Let's take a historical perspective: what was the first object-oriented
system and what was it's purpose?  I propose a candidate which will come
as no surprise to anyone, SIMULA-67.  Oh yes, SIMULA-67, the father of
SMALLTALK.  Oh yes, SIMULA-67, the frequently cited language in papers
on abstract data types.  Oh yes, SIMULA-67 the language cited as an
inspiration to the designers of the Burroughs 6700 computer, the first
computer with an operating system written in ALGOL.

But just what was the purpose of SIMULA-67, contrasted with the purpose
of ALGOL-60 on which it was based?

SIMULA-67 was designed to for discrete-event simulation applications.
ALGOL-60 was first devised to express mathematical algorithms.  What is
simulation and how is it different from a mathematical algorithm?  Can we
agree that a simulated world consists of "objects"?  What are the
characteristics of such objects, at least relative to the simulation?
Each has a *lifetime* and each has *behavior*.  Each object is "doing
it's own thing" acquiring and releasing resources, even being a resource
itself.  Each object can be identified with a separate process.

Comments?

Jan Cornish

----------------------------------------------------------------

fairley@wanginst.UUCP (Dr. Richard Fairley) (01/29/85)

> I have recently been involved in some discussions in which the topic
> of so-called "object-oriented" languages and programming techniques
> has been explored. Despite the fact that "everybody knows" that
> Smalltalk-80 is "object-oriented" and "everybody knows" (or pretends
> that they do) what "object-oriented programming" is, this same
> group of "everybody"s is having a hard time coming up with a rigorous
> definition of those terms which goes beyond one of the two following:
> 
> 1) The term is self-explanatory: the orientation of the language/program
>    is towards the "object". This causes the discussion to move in
>    the direction of defining an "object", and how exactly the language
>    or program is oriented in that direction.
> 
> 2) The term is defined by example: if somebody says a language is "object-
>    oriented" and most people agree, then the language is object-oriented
>    (the "science fiction" definition approach - "science fiction" is what
>    "science fiction authors" write, "science fiction editors" buy, and
>    "science fiction fans" read).
> 
> Neither of these approaches makes anybody particularly happy. Nobody's
> been able to find an accepted definition in the literature, either.
> So, the question is:
> 
> Is there a definition of the term "object-oriented" which is both descriptive
> of all current uses of that term and accepted by all who currently use it?
> If not, can such a definition be constructed?
> 
> I would be interested in hearing from anybody who has any ideas relating
> to this topic.
> 
>                                         Bill Laubenheimer
> ----------------------------------------UC-Berkeley Computer Science
>      ...Killjoy went that-a-way--->     ucbvax!wildbill

In my view, object-oriented means data abstraction PLUS inheritance and
dynamic binding; although most data abstraction languages use strong type 
checking, which is inconsistent with dynamic binding.  By data abstraction, 
I mean separation of specification from implementation, information hiding, 
and state retention within the object.  

The term object-oriented has been appropriated by different disciplines: 
database, architecture, operating systems, and programming languages all use 
the term with different meanings.  The term is especially confused within the
programming field because Grady Booch and the Ada crowd use the term for
what most people refer to as data abstraction; i.e., information hiding
with state retention and strong type checking.

The easiest way to distinguish object-orientation from data abstraction is
to say it's what Smalltalk does that Ada does not.  I think you will find that 
the Smalltalk people at Xerox PARC have the historical edge on use of the term.


				Dick Fairley
				decvax!wanginst!fairley

ekrell@ucla-cs.UUCP (01/30/85)

> >< 
> >   I read this somewhere: a procedure-oriented language represents the
> > behavior of a program by describing the effect of applying procedures
> > to different kinds of arguments (here procedures being a broad term
> > including assignments, arithmetic operators, etc).
> >   An object-oriented language does it by describing the effect of applying
> > different procedures (methods) to a specific object.
> > 
> 
> The definition is lacking two important things:  the definition of 'arguments'
> and the definition of 'objects'.  After all, an argument could, in some contexts
> be considered an object.
> 
> 				robert
> -- 
> Robert Viduya
>     Office of Computing Services
>     Georgia Institute of Technology, Atlanta GA 30332
>     Phone:  (404) 894-4669
> 
> ...!{akgua,allegra,amd,hplabs,ihnp4,masscomp,ut-ngp}!gatech!gitpyr!robert
> ...!{rlgvax,sb1,uf-cgrl,unmvax,ut-sally}!gatech!gitpyr!robert

*** REPLACE THIS LINE WITH YOUR MESSAGE ***
-- 
    Eduardo Krell               UCLA Computer Science Department
    ekrell@ucla-locus.arpa      ..!{sdcrdcf,ihnp4,trwspp,ucbvax}!ucla-cs!ekrell

ekrell@ucla-cs.UUCP (01/30/85)

> >< 
> >   I read this somewhere: a procedure-oriented language represents the
> > behavior of a program by describing the effect of applying procedures
> > to different kinds of arguments (here procedures being a broad term
> > including assignments, arithmetic operators, etc).
> >   An object-oriented language does it by describing the effect of applying
> > different procedures (methods) to a specific object.
> > 
> 
> The definition is lacking two important things:  the definition of 'arguments'
> and the definition of 'objects'.  After all, an argument could, in some
> contexts be considered an object.

  I've read several definitions of what people think is object-orientation
and I think that most of them confuse it with ADTs (Abstract Data Types),
which are "objects" in the sense that they represent physical or abstract
objects such as a person or a stack, where the specification of the operations
on these objects  is separated from their implementation.
  This is nice (Information Hiding principle, etc) but that doesn't make
a language object-oriented. Ada and Modula-2 have all these goodies but
that doesn't make them object-oriented languages. I think people who know
SMALLTALK would agree with me.
  It is true that there's an analogy in applying a method to an object
and an operation to an ADT, but the way an expression "f(x)" would be
evaluated in a object-oriented language is "look at the type of object x
is; find a method called f defined for that object and apply it to x".
In a procedure-oriented language it would be "look at the definition of f
and apply f to x".
  It's clear, then, that an object-oriented language has overloading since
you could have methods with the same name for different objects. However,
the presence of overloading in a language (like ADA) doesn't mean it is
object-oriented...
-- 
    Eduardo Krell               UCLA Computer Science Department
    ekrell@ucla-locus.arpa      ..!{sdcrdcf,ihnp4,trwspp,ucbvax}!ucla-cs!ekrell

mwm@ucbtopaz.CC.Berkeley.ARPA (01/30/85)

Since we're into definitions, let me present my favorite version. This is
from (I think - everything is stacked away in boxes) Tim Rench's SNot paper
already mentioned here.

Examples are not meant to reflect any real language.

'Data Encapsulation' - Provides modules, and data objects that only functions
in the appropriate module can touch. For instance:

	MODULE IntStack is Push, Pop ;
		STRUCT Stack is ... ;
		PROCEDURE Push is ... ;
		PROCEDURE Pop is ... ;
		END IntStack ;

	x is IntStack ;
	y is Int ;

	x.Push(10) ;
	y := x.Pop() ;

'Data Abstraction' - An improved form of encapsulation, wherein the abstraction
can be reused on different data types. For instance:

	MODULE Stack(T is TYPE) is Push, Pop ;
		... ;
		END Stack ;

	MODULE List(T is TYPE) is ... ;
		END List ;

	x is Stack(Int) ;
	y is Stack(List) ;
	z is Int ;
	w is List ;

	x.Push(10) ;
	y.Push([a, b, c]) ;
	w := y.Pop() ;
	z := x.Pop() ;

Finally, a programming language is 'Object Oriented' if *everything* must
be encapsulated. In other words, Concurrent Euclid is 'Object Oriented,'
and provides encapsulation, but not abstraction. Smalltalk is 'Object
Oriented,' and provides abstraction. CLU is not 'Object Oriented,' but does
provide abstraction.

I prefer this definition because it gives a high degree of resolution when
you want to talk about a language (admittedly, it takes a lot of buzz
words).  This would be far better than allowing 'Data Encapsulation' to
disappear and 'Data Abstraction' and 'Object Oriented' to become synonyms.

I think it even correctly captures the methodology split the smalltalk
people like to talk about. If everything is in a module, then all data has
a set of routines (messages) that can be used on it, and all routines have
a set of data they are associated with. This should make thinking about
things as data objects that reply to messages easier.  Of course, whether
the methodology gets used depends on the programmer.

	<mike

robert@cheviot.UUCP (Robert Stroud) (01/31/85)

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

ian@loral.UUCP (Ian Kaplan) (02/04/85)

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

jih@usl.UUCP (Juha I. Heinanen) (02/05/85)

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?

arnold@gatech.UUCP (Arnold Robbins) (02/07/85)

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!

dick@luth.UUCP (Dick O Schefstr|m) (02/11/85)

  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

crm@duke.UUCP (Charlie Martin) (02/17/85)

Fundamentally, Smalltalk doesn't do anything differently from Ada; it
just hides it differently.  

Trying to give a talk on Object-Oriented Programming, I searched high
and low (through all the Smalltalk books, for example) for a definition
of OOP -- and found none.  Either we have to take it as an undefined
term, or we ought to find a definition.  I'm unsatisfied with the
definition that has been offered by several people ("It's what Smalltalk
does that no-one else does") because a) I can't find that (tell me the
fundamental difference between passing messages and passing parameters
by name) and b) it makes "Object-Oriented Programming" == "SmallTalk
Programming" which seems to eliminate any chance of using the term or
the idea usefully in anything BUT SmallTalk.

Personally, I think the term should be discarded as being too fuzzy for
scientific use.  First, let's find out just what an Object is!

-- 
		Opinions stated here are my own and are unrelated.

				Charlie Martin
				(...mcnc!duke!crm)

		"I am not a number, I'm a free variable!"

ted@scc.UUCP (Ted Goldstein) (02/19/85)

> Fundamentally, Smalltalk doesn't do anything differently from Ada; it
> just hides it differently.  
> 
> Trying to give a talk on Object-Oriented Programming, I searched high
> and low (through all the Smalltalk books, for example) for a definition
> of OOP -- and found none.  Either we have to take it as an undefined
> term, or we ought to find a definition.  I'm unsatisfied with the
> definition that has been offered by several people ("It's what Smalltalk
> does that no-one else does") because a) I can't find that (tell me the
> fundamental difference between passing messages and passing parameters
> by name) and b) it makes "Object-Oriented Programming" == "SmallTalk
> Programming" which seems to eliminate any chance of using the term or
> the idea usefully in anything BUT SmallTalk.
> 
> Personally, I think the term should be discarded as being too fuzzy for
> scientific use.  First, let's find out just what an Object is!
> 
> -- 
> 		Opinions stated here are my own and are unrelated.
> 
> 				Charlie Martin
> 				(...mcnc!duke!crm)
> 
> 		"I am not a number, I'm a free variable!"

A friend of mine defines an `object' as "Data with an Opinion."
That is, using the type of the object, a function/operation is selected
which is appropriate to that type. This is nothing new to computer
languages. Addition is different for integer and floating point numbers.
Yet syntactically a programmer coding in many high level langauges
write a + b and leave the work to the compiler to determine whether to 
use integer add or floating add primitives.

Smalltalk-80, and other object-oriented languages promote this concept 
so that it is uniformally applied to all operations and types, whether they
are system defined or user defined.


But to come up with a less fuzzy opinion:
More formally, an "Object" is a type defintion with a 
closure on what operations may be performed on it.
Objects are similar to ADA's packages when used in conjunction with
ADA generic calls.  Almost all  Smalltalk-80 objects are defined in a
hierarchical fashion.  ADA Packages can be hierarchically
composed too, but the generic operations cannot be used 
after the first level of the hierarchy. The hierarchical nature is natural
in Smalltalk-80 because binding between the generic call and the 
actual function  (method) is dynamic. That is, it occurs at
run time. I think Smalltalk-80 is superior to ADA in this
respect, because more code is re-usable because operations
(when apropriate) tend to be defined at higher levels of the hierarchy.


ADA generic operations are selected by the type of all of its  arguments,
while Smalltalk operations are selected by the first argument only.
C++ is similar to ADA in this way; multiple argument type binding
on generic operations are a property of compile time bindings.


C++ combines some of Smalltalk-80 and ADA's power.  Like ADA,
C++ has generic operations. These are frequently resolved at 
compile time, and thus  incur no addtional penalty.
Some generic operations in a hierarchically defined types
cannot be known at compile time.  Smalltalk and C++
both have dynamic binding available when the inheritance cannot be
determined (This is known as virtual functions in C++). ADA must
know all package defintions and make resolve all generic functions
at compile time.

I hope we see more of C++ in the world.
-- 

			    Sincerely,
				Ted Goldstein,
				Freelance Consultant

	     "Don't thank me, thank Uni" 
		 from 'This Perfect Day' by Ira Levin



ihnp4!pesnta  -\
fortune!idsvax -> scc!ted
ucbvax!twg    -/    Santa Cruz, California       (408) 662-3112