Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/5/84; site tove.UUCP
Path: utzoo!watmath!clyde!cbosgd!ihnp4!zehntel!tektronix!decvax!bellcore!allegra!mit-eddie!godot!harvard!seismo!umcp-cs!tove!koved
From: koved@tove.UUCP (Larry Koved)
Newsgroups: net.lang,net.lang.st80
Subject: Re: Re: What is Object-Oriented
Message-ID: <119@tove.UUCP>
Date: Tue, 5-Feb-85 23:21:53 EST
Article-I.D.: tove.119
Posted: Tue Feb  5 23:21:53 1985
Date-Received: Tue, 12-Feb-85 06:26:55 EST
References: <3013@umcp-cs.UUCP> <117@tove.UUCP>
Organization: U of Maryland, Laboratory for Parallel Computation, C.P., MD
Lines: 94
Xref: watmath net.lang:1418 net.lang.st80:188

> In article <3013@umcp-cs.UUCP> koved@umcp-cs.UUCP (Larry Koved) writes:
> >There are languages which use overloading and/or inheritence, but
> >are not OO, and visa versa.
> 
> I'd be interested in an example of inheritence without OO.  What one
> inherits in OO is operators and local variables.  Is there something
> else to inherit?
> 
Lisp Flavors (which you mention below) is an example of a lanugage
which has is a combination of object-oriented and non-object-oriented
features in a single language.  Lisp is not object oriented, but the
flavors package in lisp is object oriented.  I would not classify
Lisp as an object oriented language;  only the flavors part is
object oriented (to a degree).  I do not know of a language which
only has inheritence, but not objects.  A language could be defined
in which a data type could inherit properties of an existing data type.

For example:
In Pascal, if a type (call it A) uses another type in its definition
(call it B), then type A inherits properties of type B.

My thoughts in this area are a little fuzzy since I have not thought
about it very much.

> >Finally, it should also be noted that there are different degrees of
> >being OO.  Smalltalk is almost at one extreme, while Modula-2 is almost
> >at the other extreme.  
> 
> Not Fortran or Forth at the other extreme?  Modula-2?  Do you mean
> there are different KINDS of OO, with Modula-2 and Smalltalk being
> prototypical examples, or do you really mean degrees?

I would probably like to stick with my original statement of there
being extremes in being OO.  Yes, Modula-2 and Smalltalk
prototypical examples of OO languages.
The degrees of which I am speaking are the degrees to which the
language makes the sharp distinction about object manipulation.
In particular, how well the language protects the objects, their
internal representations and access to the procedures which manipulate
the representation.

For example, in Modula-2 (and ADA for that matter), you can hide
the representation and implementation of an object in the implementation
of the modules.  The definition of the object and the procedures which
manipulate the objects can be made public (if so desired), but
those procedures which are not defined to manipulate the object
can not gain access to the object's representation.

The same is true of Smalltalk.  The difference is that Smalltalk
attempts to enforce the rules across all objects which are defined
and instantiated.  This is not so for Modula-2 and ADA where you
can define objects where any procedure can manipulate the internal
representation.

The difference is that Modula-2 allows object representation protection,
but Smalltalk always requires that the object be protected.

> 
> >The performance of the language (instructions
> >per second) is a major consideration in deciding the degree to which
> >a language's design is OO.  Being extremely OO is expensive in
> >processing time and/or space.
> 
> Now this is an interesting issue.  Why should OO be expensive?
> It need not be, because it need not be a runtime feature of a language.
> Smalltalk is mostly interpreted, and so is slow for that reason,
> not because it is OO.  The Maryland Flavors Package under Franz
> Lisp allows compiled methods, flavors etc, and so runs not too
> much slower than bare Lisp.  And a completely statically checked
> and implemented OO language should be as fast as any other at runtime.
> (Is c++ something like this?  I'm not sure.)
> Might be slow to compile with current technology--but we haven't had
> much practice at building fast OO compilers.

Yes, the issue about performance of systems which require protecton
is interesting.  If and when type checking can be done statically,
the cost is much lower.  You make refrence to flavors.  The flavors
part of lisp is object oriented, but the rest of lisp upon which
flavors is implemented is not.  I suspect that this makes a difference.
When looking a security (protection) oriented systems, there are costs
incurred due to the protection mechanisms.  Once you start to do
multi-programming, then you get many different types of protection
problems which do not occur in uni-programming systems (and languages).
This is also a factor in why protected systems incur a heavy cost
at run-time.

> -- 
> Spoken: Mark Weiser 	ARPA:	mark@maryland	Phone: +1-301-454-7817
> CSNet:	mark@umcp-cs 	UUCP:	{seismo,allegra}!umcp-cs!mark
> USPS: Computer Science Dept., University of Maryland, College Park, MD 20742
-- 
Spoken: Larry Koved
Arpa:   koved.umcp-cs@CSNet-relay
Uucp:...{allegra,seismo}!umcp-cs!koved