Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!sun-barr!decwrl!shelby!neon!pallas
From: pallas@Neon.Stanford.EDU (Joe Pallas)
Newsgroups: comp.object
Subject: Re: Evaluating "Object-Oriented" Progra
Message-ID: <1990Jan9.202519.25310@Neon.Stanford.EDU>
Date: 9 Jan 90 20:25:19 GMT
References: <638@ajpo.sei.cmu.edu> <135300019@p.cs.uiuc.edu>
Organization: Computer Science Department, Stanford University
Lines: 54

In article <135300019@p.cs.uiuc.edu> johnson@p.cs.uiuc.edu writes:

>In my opinion, the three major characteristics of an OOP language are

>1. data abstraction
>2. inheritance
>3. polymorphism caused by late-binding of procedure calls

Okay, that looks like a subset of my list, which appears below.

>I've never been able to understand why information hiding isn't just
>an aspect of data abstraction.  

I think this is a common point of miscommunication.  Many people
(perhaps most) treat protection or privacy as part of data
abstraction.  I prefer to make a distinction between abstraction as
voluntary and protection or privacy as involuntary.  For example, it
isn't hard to do data abstraction in C using structs, but it is
impossible to enforce protection.  Likewise, in Ada, you can choose
whether or not your data type is private, but your client can choose
to treat it abstractly even if it isn't private.

>I also think that data abstraction
>and abstract data types are synonyms, but maybe I'm just stupid.

This may not be presented very well, but here's my view on that (and
my list):

1) Data abstraction is a property of a language,
	abstract data types are things in the language/implementation.

2) Protection is a property of a language,
	messages are things in the language/implementation.
	(in my view, messages are things which explicitly
	cross protection boundaries, like protected procedure calls)

3) Bundling code and data together is a property of a language,
	objects are things in the language/implementation.

4) Universal polymorphism is a property of a language,
	run-time types are things in the language/implementation.

5) Inheritance is a property of a language,
	inheritance hierarchies are things in the language/implementation.

As far as the list itself goes, many people combine (1) and (2).
Various people call (2) or (3) or both ``encapsulation'', so I have
given up on that word.  Some people feel (5) is not necessary; I
believe that (4) without (5) is not very useful.

I'd be interested in comments on either my property-of/thing-in
approach or the list itself.

joe