Re: Re^2: Integrating concurrent & O-O programming

[sakkinen@tukki.jyu.fi (Markku Sakkinen)]

In article <481@cui.unige.ch> anders@cuisun.unige.ch writes:
>In article <477@cui.unige.ch> oscar@cui.unige.ch (NIERSTRASZ Oscar) writes:
>
>>In object-oriented languages, there are (at least) *two* clients to
>>object classes: the clients of the object instances, and subclasses
>>that wish to inherit the code.  If you view inheritance as purely a
>
>Another interface is the interface to other instances of the same class.
>Try implementing the class integer with a method add in Smalltalk
>without exposing your internal representation.
>
>You can actually distinguish four different interfaces:
>
>1- The interface to self of the same class. No encapsulation wanted here :-)
>
>2- The interface to self of some other (super)class.
>
>3- The interface to some other instance of the same class.
>
>4- The interface to some other instance of some other class.
>
>In the programming language PAL of the Avance prototype (see oopsla88)
>we made no distinction between 2 and 3 and had three kinds of operations.
>Public operations could be used by 1-4.
>Private operations could be used by 1-3.
>Hidden operations and instance variables could be used by 1.

I think this is very important and interesting (because I have myself
thought about these matters :-) ).
Note that Smalltalk-80 (TM) and some other OOPL's make no difference
between 3 and 4 nor between 1 and 2,
while perhaps the majority of OOPL's (as well as CLU, Modula-2,
and Ada(R) - for which case 2 is vacuous because they have no inheritance)
make no difference between 1 and 3.

Case 2 can be further subdivided on the basis of whether the other
class is a _sub_ or _super_ class of the class in question.
(In many models of multiple inheritance, classes may even get
indirectly connected via a common subclass.)
Rather many OOPL's allow a class designer to specify that some features
shall not be visible to _sub_classes, but I can't remember reading about any
language that allows the same toward _super_classes.

>The concept of a "friend functions" in C++ is related to this and further
>subdivides 4. [I am not a c++ expert though so I may be wrong].

No, you are right.

> [...]

Markku Sakkinen
Department of Computer Science
University of Jyvaskyla (a's with umlauts)
Seminaarinkatu 15
SF-40100 Jyvaskyla (umlauts again)
Finland