Xref: utzoo comp.lang.smalltalk:472 comp.lang.c++:813
Path: utzoo!mnetor!uunet!husc6!bbn!rochester!ritcv!mjl
From: mjl@ritcv.UUCP (Mike Lutz)
Newsgroups: comp.lang.smalltalk,comp.lang.c++
Subject: Re: Object Orientation and The Truth
Message-ID: <211@ritcv.UUCP>
Date: 17 Feb 88 01:13:29 GMT
Reply-To: mjl@ritcv.UUCP (Michael Lutz)
Organization: Rochester Institute of Technology, Rochester, NY
Lines: 71

In article <10085@ulysses.homer.nj.att.com> jss@hector (Jerry Schwarz) writes:
>
>I will rephrase my observation: Inheritance is the major  feature
>that distinguishes "object-oriented" Smalltalk and C++ from other
>languages such as CLU, ML, Ada, Modula-2, ... that support notions of
>user defined types.
>
>I consider data encapsulation a very important aspect of programming,
>and both languages support it to some extent.  But the static types
>of C++ are so different from the dynamic types of Smalltalk that I
>don't believe it is fair to say that they share data encapsulation
>features.

"Sharing" is a relative term.  Compared to Ada, Modula-2, etc., I'd say
C++ & Smalltalk have a lot in common.  [enter JJ Starbuck mode] "But
then, as my pappy used to tell me, a difference of opinion is what makes
a horse race." [end JJS mode].

>As for "multiple objects of the same abstract type"  I can't imagine
>a language that has a notion of user defined type that doesn't
>support multiple things (objects or values) of a type.

All depends on what you man by "type".  Back in the early days of Pascal,
when it was the language that was going to save the world, A. N. Haberman
wrote a short paper which basically said that Pascal's "types" were
simply syntactic sugar for good ole' data structures.  His definition
of "type" was one where the internal state of an element of the type (read:
object of the class) could only be altered by operations defined on the
type (read: encapsulation).

Now Ada and Modula provide encapsulation, but do not provide "types" in
this sense, as you can't create multiple instances of the
package/module that provides the encapsulation.  (You might be able to
cobble something up using Ada tasks, but then you deserve the trouble
you'll create for yourself).  If Pascal has "types", then you agree
with Jerry (I think); if you think "types" should meet this more
restrictive interpretation, you agree with me (and Haberman - appealing
to authority).  It's also possible, of course, to provide such types
without inheritance, or with other mechanisms such as parametric types
(a weak form of which is provided by Ada generics).

>>For the record: Peter Wegner presented a paper at OOPSLA 87 which gave
>>a taxonomy of various forms of "objectness".  Worth a read, as it
>>does try to provide consistent terminology.  
>
>Thanks for the pointer.  He certainly supports my observation.  I
>quote
>
>        An object-based language is object-oriented if its objects
>        belong to classes and class hierarchies may be incrementally
>        defined by an inheritance mechanism. That is:
>
>	object-oriented = objects + classes + inheritance

No problem here (and no conflict either).  My point was that objects +
classes (or instances + types) are interesting in their own right, even
without inheritance.  I applaud Wegner's effort to bring some order out
of terminological chaos.  But as Jerry has already shown in his
"applicative language" example, there are holes in this classification
scheme already.

[I'm not a fan of applicative languages, so I'd probably consider such
a language with inheritance a platypus - an interesting genetic experiment,
but well out of the main stream :-)].

Mike Lutz
rochester!ritcv!mjl
-- 
Mike Lutz	Rochester Institute of Technology, Rochester NY
UUCP:		{allegra,seismo}!rochester!ritcv!mjl
CSNET:		mjl%rit@csnet-relay.ARPA