Path: utzoo!attcan!uunet!microsoft!jimad
From: jimad@microsoft.UUCP (JAMES ADCOCK)
Newsgroups: comp.object
Subject: Re: What is OOP? (not asking for intro. stuff)
Message-ID: <50014@microsoft.UUCP>
Date: 13 Feb 90 18:02:52 GMT
References: <+B8|X-@rpi.edu>
Reply-To: jimad@microsoft.UUCP (JAMES ADCOCK)
Organization: Microsoft Corp., Redmond WA
Lines: 42

In article <+B8|X-@rpi.edu> fargo@pawl.rpi.edu (Irwin M. Fargo) writes:
...
>encapsulated objects

If you seriously look at any "object oriented" code, you will discover
that encapsulation is not an important criterion in presently programmed
OOP code.  I'd claim inheritence is antagonistic to encapsulation.  Not
to imply we shouldn't be using inheritence, nor that we shouldn't be better
encapsulating.  Just that "we" aren't.

>message selectors and methods

"Message selectors" and "methods" are Smalltalk-ese.  Other OOPLs use
other terminology for techniques spanning the whole range of speed verses
flexibility trade-offs.  And more modern optimizing OOPL compilers make
many of these trade-offs too, regardless of the terminology called out
in the language manual.

>classes

"Self" being an interesting example of an OOPL without classes.

>a class hierarchy

Ditto.

>Do you think it makes sense to try and quantify OOP in this manner?  If so,
>what ideas do you think make a language an OOPL?

I don't think it makes any more sense to try to quantify OOP than it makes
sense to quantify the "structured methodology"-nese or "top-down"-edness
of a design.  Given that OOP is good, everything must be OOP, [whether it
is, or not]  My claim is that in less than five years *everything* is
going to be "object oriented."

More sensibly, I think there are some reasonable distinctions that can
be made.  "Class-oriented" programming of Smalltalk verses "Object-oriented"
programming of Self.  [I'd claim the widely used "object oriented" is
a misnomer for what is actually "class-oriented".] Delegation verses 
inheritence.  Single verses multiple inheritence.  Strict verses non-strict
typing.  Distinctions based on method dispatch methodology are increasingly
non-sensical as we head towards good optimizing compilers.