* Integrating concurrent & O-O programming
@ 1989-11-15 19:30 Bill Wolfe
1989-11-21 4:09 ` Tim Atkins
0 siblings, 1 reply; 9+ messages in thread
From: Bill Wolfe @ 1989-11-15 19:30 UTC (permalink / raw)
[This is taken from Object-Oriented Development, edited by Dennis
Tsichritais, Centre Universitaire d' Informatique, Universite'
de Geneve, a non-copyrighted summarization of research activity;
the specific paper is "Concurrency Issues in Object-Oriented
Programming, by M. Papathomas, page 207. It describes ideas which
are relevant to the current Ada 9X language revision process.]
Although the integration of object-oriented and concurrent programming
is promising for the development of software for such applications, the
design of programming languages that keep up with this promise is a
difficult task. The concurrent features of a language may interfere
with its object-oriented features making them hard to integrate in a
single language or cause many of their benefits to be lost. For instance,
encapsulation in sequential object-oriented programming languages protects
the internal state of objects from arbitrary manipulation and ensures its
consistency. If concurrent execution is introduced in a language
independently of objects it will compromise encapsulation, since concurrent
execution of the operations of objects may violate the consistency of
their internal state...
...consider the interference that occurs between class inheritance
and encapsulation when subclasses are allowed to access freely the
instance variables of the parent class [Sny86]. In this case we may
say that support for inheritance diminishes the degree of encapsulation
that was achieved without inheritance...
...we identify two categories of COOPLs [Concurrent Object-Oriented
Programming Languages]. We will call _orthogonal_ the category of
languages where objects are unrelated to concurrency, and _non-orthogonal_
the category of languages where objects have some predefined properties
concerning concurrency... According to whether or not a language supports
objects of different kinds, we will further subdivide the category of
non-orthogonal languages into the _non-uniform_ and _uniform_ categories.
Languages in the uniform category support only one kind of object whereas
language in the non-uniform category split the object world into two kinds
of objects: those that serialize the execution of their operations and
those that do not. Concurrent execution may be expressed by explicitly
creating new threads of control, independently of objects, that communicate
and synchronize by invoking the operations of shared objects. Another
approach is to consider objects as active entities and express concurrent
execution and synchronization by the creation of objects and their
interaction. We use these two approaches to subdivide the uniform category
into the categories _integrated_ and _non-integrated_. For languages in
the integrated category concurrent execution is expressed by interaction
of objects whereas in the non-integrated category another concept like a
process or activity is used for expressing concurrent execution...
The non-orthogonal class has the advantage of preventing the problems
that could occur by using "unprotected" objects in [a] concurrent
environment. Objects of sequential nature may be implemented in
much the same way as in sequential languages. The mutually exclusive
execution of the object's operations is handled automatically by the
language. The distinction between different kinds of objects
characterizing the non-uniform category presents some disadvantages
compared to the uniform one. The programmer has to decide in advance
if a certain object should be of the "protected" or "unprotected" type.
Type hierarchies... are typically kept disjoint... introducing a certain
redundancy in the class hierarchy... The integrated approach has the
advantage that concurrent applications are structured in terms of objects
which are the units of concurrent execution. The communication and
synchronization of objects is expressed at the object interface which
is clearly defined...
Support for mechanisms similar to data abstraction in COOPLs is even
more badly needed than in sequential languages but also is hard to
provide. Ideally the data abstraction mechanism provided by COOPLs
should separate the aspects of concurrent execution relevant to an
object's implementation from the concurrent behavior of the abstraction...
For reaching such goals we would need a way for describing the externally
observable behavior of objects, be able to and automatically check that
the realization of objects satisfies the specifications. This goal seem[s]
unreachable in the near future. It would be more reasonable to provide
compromises by designing abstraction mechanisms that capture more
information about the behavior of active objects than abstract data
types. A parallel to this approach may be drawn with the way ADTs are
used in sequential programming languages and the use of assertions
instead of supporting algebraic specifications and automatic verification
of programs...
Concurrency is not orthogonal to other aspects of object-oriented
programming. Although several object-oriented languages that provide
support for concurrent programming have been designed and implemented
their concurrent features interfere with their object-oriented features.
Furthermore, the approaches taken for concurrency may have a considerable
impact on the structure of applications in a way that is contrary to the
principles underlying object-oriented programming...
Although abstraction mechanisms conveying more information than ADTs
about the behavior of objects are badly needed in COOPLs, very little
has been done in this direction by COOPLs. This may be explained by
the fact that [there] does not seem to exist a consensus on formal
models for the specification of the behavior of concurrent systems
that would provide a basis for development of abstraction mechanisms
that would extend the data abstraction mechanism to concurrent languages...
We believe that the development of type systems for COOPLs is intimately
related to the development of formal models for the specification of the
time-dependent behavior of objects, and the development of abstraction
mechanisms that will extend data abstraction to include more information
about such behavior.
Exception handling mechanisms are even more important in concurrent
systems than they are in sequential ones. The failure of a process
should not entail the failure of the whole systems since other processes
may be able to proceed.
Persistence is useful for the development of a host of applications.
Providing support for persistence in a programming language frees the
application programmer from the burden of explicitly managing persistence
by using files. The atomicity properties of transactions are especially
attractive in a system that has to deal with long lived persistent data.
Although persistence on its own does not seem to interfere with concurrency
features of a language it is not the same concerning transactions. The
noninterference property of transactions seems contrary to the close
interaction and communication of processes that characterizes concurrent
programming and the independence of objects promoted by object-oriented
programming.
The full integration of concurrency with all the other aspects of
object-oriented programming presents several problems that deserve
more attention... further work is required for gaining more insight
in the nature of these problems and for developing languages that
provide satisfactory solutions.
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Integrating concurrent & O-O programming
1989-11-15 19:30 Integrating concurrent & O-O programming Bill Wolfe
@ 1989-11-21 4:09 ` Tim Atkins
1989-11-22 22:08 ` 3929
` (4 more replies)
0 siblings, 5 replies; 9+ messages in thread
From: Tim Atkins @ 1989-11-21 4:09 UTC (permalink / raw)
In article <7062@hubcap.clemson.edu> wtwolfe@hubcap.clemson.edu (Bill Wolfe) writes:
> ...consider the interference that occurs between class inheritance
> and encapsulation when subclasses are allowed to access freely the
> instance variables of the parent class [Sny86]. In this case we may
> say that support for inheritance diminishes the degree of encapsulation
> that was achieved without inheritance...
I have heard this before and, frankly, I don't get it. The subclass
has inherited data structure definition from the parent class. Therefore
its instances will contain instances of the parent data structure. This
is totally local to the object! Only the definition was inherited. Why
is this a bad thing? Why does it break encapsulation? I understood the
encapsulation wrt data provided by OO techniques to simply state that instance
data should not be accessed directly but only through a method defined on
the class. Therefore, inheritance does not seem to break encapsulation.
I would appreciate it if someone could set me straight here.
- Tim
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Integrating concurrent & O-O programming
1989-11-21 4:09 ` Tim Atkins
@ 1989-11-22 22:08 ` 3929
1989-11-22 22:37 ` Dan Weinreb
` (3 subsequent siblings)
4 siblings, 0 replies; 9+ messages in thread
From: 3929 @ 1989-11-22 22:08 UTC (permalink / raw)
In article <1667@osc.COM> tma@osc.UUCP (Tim Atkins) writes:
>I have heard this before and, frankly, I don't get it. The subclass
>has inherited data structure definition from the parent class. Therefore
>its instances will contain instances of the parent data structure. This
>is totally local to the object! Only the definition was inherited. Why
>is this a bad thing? Why does it break encapsulation? I understood the
>encapsulation wrt data provided by OO techniques to simply state that instance
>data should not be accessed directly but only through a method defined on
>the class. Therefore, inheritance does not seem to break encapsulation.
>
>I would appreciate it if someone could set me straight here.
As I understand your question, here is (one of) the rub(s):
Class A inherits from class X. In many OO programming languages if not
most that means that A gets to access X's local data items. Thus, if X
had a data item 'foo', code from class A could directly access 'foo'.
This means that class doesn't just depend upon the interface of X but
also depends upon the implementation of X. This means that if X changes,
A may have to change (and anything which is a descendant of X including
all of A's descendants). This tends to make those classes near the root
of an inheritance heirarchy become "rigid" very quickly, since changes
can "ripple" down the heirarchy. This is viewed as a bad thing since the
whole point of OO is to avoid "ripples" which propagate through a software
system.
Note that some languages help provide solutions for this. For example, C++
has the concepts of public, protected, and private items in a class, to help
in restricting access to data members. When this is combined with the
ability to inline functions, you can provide interface routines for every
data member that is meant to be accessable in an efficient manner and thus
hide the implementation from sub-classes without taking a major performance
hit. (By the way, I'm still not totally sold on C++ but this aspect is
certainly nice).
Thanks,
--------------------------------------------------------------------------------
Brian R. Gilstrap ...!{ texbell, uunet }!swbatl!uucibg OR uucibg@swbatl.UUCP
One Bell Center +----------------------------------------------------------
Rm 17-G-4 | "Winnie-the-Pooh read the two notices very carefully,
St. Louis, MO 63101 | first from left to right, and afterwards, in case he had
(314) 235-3929 | missed some of it, from right to left." -- A. A. Milne
--------------------------------------------------------------------------------
Disclaimer:
Me, speak for my company? You must be joking. I'm just speaking my mind.
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Integrating concurrent & O-O programming
1989-11-21 4:09 ` Tim Atkins
1989-11-22 22:08 ` 3929
@ 1989-11-22 22:37 ` Dan Weinreb
1989-11-23 2:52 ` Ziaul Masum Hasan
` (2 subsequent siblings)
4 siblings, 0 replies; 9+ messages in thread
From: Dan Weinreb @ 1989-11-22 22:37 UTC (permalink / raw)
In article <1667@osc.COM> tma@osc.COM (Tim Atkins) writes:
In article <7062@hubcap.clemson.edu> wtwolfe@hubcap.clemson.edu (Bill Wolfe) writes:
> ...consider the interference that occurs between class inheritance
> and encapsulation when subclasses are allowed to access freely the
> instance variables of the parent class [Sny86]. In this case we may
> say that support for inheritance diminishes the degree of encapsulation
> that was achieved without inheritance...
I have heard this before and, frankly, I don't get it.
There is definitely a degree of truth in what Wolfe says. To get down
to brass tacks, the problem arises if I write a base class B, and you
make from it a derived class D. (In other jargon, D inherits from B.)
Your function members (methods) on D freely use the data members
(instance variables) in B. Fine. Time passes. I now go back and
modify B, either to add new features or improve performance. In so
doing, I change the internal guts of the implementation of B, which
are supposedly hidden by virtue of encapsulation. This is OK for
outside "users" of B. However, D has "inside information": it knows
about the raw internal guts of B, namely the data members (instance
variables). So my changes to B, which are supposed to be invisible
and hidden by the encapsulation, break D.
Smalltalk-80 really has this problem, and there is no language
mechanism in Smalltalk-80 that deals with this. (I was told this
by one of the great Smalltalk-80 experts.)
C++ provides a feature specifically intended to address this
phenomenon, namely "protected", which allows the writer of B to
specifically distinguish between those data members that are hidden to
writers of derived classes, and those that are visible. This seems to
me like a promising approach. Only many years of experience with many
megalines of code will tell us all how well this works. Perhaps there
are other languages out there in widespread use that try to deal with
this problem.
Dan Weinreb Object Design, Inc. dlw@odi.com
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Integrating concurrent & O-O programming
1989-11-21 4:09 ` Tim Atkins
1989-11-22 22:08 ` 3929
1989-11-22 22:37 ` Dan Weinreb
@ 1989-11-23 2:52 ` Ziaul Masum Hasan
1989-11-23 9:46 ` Re^2: " NIERSTRASZ Oscar
1989-11-23 14:56 ` BJORNERSTEDT Anders
4 siblings, 0 replies; 9+ messages in thread
From: Ziaul Masum Hasan @ 1989-11-23 2:52 UTC (permalink / raw)
In article <1667@osc.COM> tma@osc.UUCP (Tim Atkins) writes:
>In article <7062@hubcap.clemson.edu> wtwolfe@hubcap.clemson.edu (Bill Wolfe) writes:
>> ...consider the interference that occurs between class inheritance
>> and encapsulation when subclasses are allowed to access freely the
>> instance variables of the parent class [Sny86]. In this case we may
>> say that support for inheritance diminishes the degree of encapsulation
>> that was achieved without inheritance...
>
>
>I have heard this before and, frankly, I don't get it. The subclass
>has inherited data structure definition from the parent class. Therefore
>its instances will contain instances of the parent data structure. This
>is totally local to the object! Only the definition was inherited. Why
>is this a bad thing? Why does it break encapsulation? I understood the
>encapsulation wrt data provided by OO techniques to simply state that instance
>data should not be accessed directly but only through a method defined on
>the class. Therefore, inheritance does not seem to break encapsulation.
>
>I would appreciate it if someone could set me straight here.
>
>- Tim
Aren't you confusing runtime behavior with compilation time?
Encapsulation hides representation.
Accessing instance variables means you can directly use or refer to that
variable in any method that you define in the subclass (S) of a class (C).
In other words, the scope of this variable defined in C spans up to the
subclass. Of course, this violates encapsulation (or information hiding).
If the representation of the instance variable is changed in C (say, from
array to linked list), all the methods in all the subclasses down the class
hierarchy that used that variable directly have to be rewritten and recompiled.
Had we used method to access (refer) that variable, modification in one class
was sufficient.
Languages vary in defining what to inherit.
In smalltalk subclasses inherit both instance variables and methods. Any method
can directly use any inherited instance variable. But any other class that is
not a suclass of a class C, but simply uses C by creating an instance of it, can
access variables of C only through methods.
In some other languages a class can access instance vriables of any other
class only through methods.
C++ has a flexible mechanism in defining what to inherit i.e., public, private, friend constructs.
Masum Hasan
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re^2: Integrating concurrent & O-O programming
1989-11-21 4:09 ` Tim Atkins
` (2 preceding siblings ...)
1989-11-23 2:52 ` Ziaul Masum Hasan
@ 1989-11-23 9:46 ` NIERSTRASZ Oscar
1989-11-23 16:18 ` BJORNERSTEDT Anders
1989-11-23 14:56 ` BJORNERSTEDT Anders
4 siblings, 1 reply; 9+ messages in thread
From: NIERSTRASZ Oscar @ 1989-11-23 9:46 UTC (permalink / raw)
tma@osc.COM (Tim Atkins) writes:
>In article <7062@hubcap.clemson.edu> wtwolfe@hubcap.clemson.edu (Bill Wolfe) writes:
>> ...consider the interference that occurs between class inheritance
>> and encapsulation when subclasses are allowed to access freely the
>> instance variables of the parent class [Sny86]. In this case we may
>> say that support for inheritance diminishes the degree of encapsulation
>> that was achieved without inheritance...
>I have heard this before and, frankly, I don't get it. The subclass
>has inherited data structure definition from the parent class. Therefore
>its instances will contain instances of the parent data structure. This
>is totally local to the object! Only the definition was inherited. Why
>is this a bad thing? Why does it break encapsulation? I understood the
>encapsulation wrt data provided by OO techniques to simply state that instance
>data should not be accessed directly but only through a method defined on
>the class. Therefore, inheritance does not seem to break encapsulation.
>I would appreciate it if someone could set me straight here.
At the level of objects, encapsulation protects the client of an object
from needing to know details of the object's representation. One simply
"sends messages", i.e., there is a well-defined interface between the
client and the object. Modifications to the representation should not affect
the client (the service may change somewhat, but the client's code is
still valid).
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
machanism for share code and interfaces within a collection of object
classes (i.e., if you are a lone programmer) then there is no reason
why subclasses should not see everything they inherit. But if you are
implementing a class library for use by other programmers, or if you
wish yourself to make use (reuse) by inheritance of existing classes,
you would like to protect subclasses from modifications made to
superclasses. That is why some languages permit subclasses to make
use only of instance variables and methods explicitly exported.
What aggravates the situation is that in order to implement useful
subclasses, you often *want* subclass instances to access (hidden)
inherited instance variables and private methods. This means that either:
1. the implementor of a subclass must completely understand not only
the source code of the superclass, but also everything inherited
by the superclass from *its* superclasses etc.
(deciphering the "yoyo" effect in the presence of self and
super can be like trying to read a program loaded with gotos)
or:
2. the interface of the superclass to inheriting subclasses must be
specified as completely as the interface of an object to
its clients.
We would prefer solution 2, but unfortunately we don't know how to do this
very well, although we try sometimes to make do with natural language.
("If you inherit from this class, make sure you don't modify variable x,
unless you ...")
Finally, when we have "concurrent objects", i.e., objects that make
use of concurrency and synchronization mechanisms in their methods,
subclasses inheriting such code must be careful about how they
extend the superclass behaviour to avoid nasty surprises.
Our experience in designing and implementing a concurrent object-oriented
language ("Hybrid" -- see OOPSLA '87) revealed that concurrency mechanisms
that seem quite reasonable at the object level, can pose difficulties
in the presence of inheritance and composition (e.g., using a concurrent
object as an instance variable can create unexpected results). Although
the conflict between concurrency mechanisms and object-oriented features
such as inheritance has been noted by many researchers, clean integration
is still an open problem.
Oscar Nierstrasz
---------------------------------------------------------------------
Dr. O.M. Nierstrasz E-mail: oscar@cuisun.unige.ch
Centre Universitaire d'Informatique Tel: 41 (22) 787.65.80
12 rue du Lac, CH-1207 Geneva Fax: 41 (22) 735.39.05
SWITZERLAND Home: 41 (22) 733.95.68
---------------------------------------------------------------------
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Integrating concurrent & O-O programming
1989-11-21 4:09 ` Tim Atkins
` (3 preceding siblings ...)
1989-11-23 9:46 ` Re^2: " NIERSTRASZ Oscar
@ 1989-11-23 14:56 ` BJORNERSTEDT Anders
4 siblings, 0 replies; 9+ messages in thread
From: BJORNERSTEDT Anders @ 1989-11-23 14:56 UTC (permalink / raw)
In article <1667@osc.COM> tma@osc.UUCP (Tim Atkins) writes:
>In article <7062@hubcap.clemson.edu> wtwolfe@hubcap.clemson.edu (Bill Wolfe) writes:
>> ...consider the interference that occurs between class inheritance
>> and encapsulation when subclasses are allowed to access freely the
>> instance variables of the parent class [Sny86]. In this case we may
>> say that support for inheritance diminishes the degree of encapsulation
>> that was achieved without inheritance...
>
>I have heard this before and, frankly, I don't get it. The subclass
>has inherited data structure definition from the parent class. Therefore
>its instances will contain instances of the parent data structure. This
>is totally local to the object! Only the definition was inherited. Why
>is this a bad thing? Why does it break encapsulation?
It does break encapsulation.
Whether or not this is desirable is another matter.
If you make the distinction between specification and implementation
of classes and considder inheritance of specifications as the
primary thing then you do want encapsulation. But if inheritance of
implementation (including representation) is the primary thing then you
dont want encapsulation. Note: You may have both inherritance of specification
and inheritance of implementation at the same time, in fact this is what you
get by default in nearly all existing oo-languages. The question then becomes
what you want to emphasize: the inheritance of an abstract datatype or the
inheritance of a concrete datatype ?
The programmer implementing a supertype may not be the same person as
the programmer implementing the subtype and may not want implementors
of subtypes to build in dependencies on, or make assumptions about, the
internal representation of the supertype (same arguments as always
for encapsulation).
Thus, yes the instance contains "instances" of the parent structure,
and yes this is totally local to the object, but you may still want
encapsulation (or partitioning) internally in the object.
If inheritance of specification is the emphasis you may still have
default inheritance of implementation. This just means that the implementor
of the subtype is liberated of the job of providing the implementation
for the supertypes. It does not mean that the implementor of the subtype
can "poke arround" in the implementation of the supertype.
Anders
---------------------------------------------------------------------
Anders Bjornerstedt E-mail: anders@cuisun.unige.ch
Centre Universitaire d'Informatique
12 rue du Lac, CH-1207 Geneva
---------------------------------------------------------------------
Tel: 41 (22) 787.65.80-87 Fax: 41 (22) 735.39.05
Home: 41 (22) 735.00.03 Telex: 423 801 UNI CH
---------------------------------------------------------------------
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Re^2: Integrating concurrent & O-O programming
1989-11-23 9:46 ` Re^2: " NIERSTRASZ Oscar
@ 1989-11-23 16:18 ` BJORNERSTEDT Anders
1989-11-26 14:04 ` Markku Sakkinen
0 siblings, 1 reply; 9+ messages in thread
From: BJORNERSTEDT Anders @ 1989-11-23 16:18 UTC (permalink / raw)
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.
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].
>2. the interface of the superclass to inheriting subclasses must be
> specified as completely as the interface of an object to
> its clients.
>We would prefer solution 2, but unfortunately we don't know how to do this
>very well, although we try sometimes to make do with natural language.
Kind 2 operations give you exactly this.
Kind 3 operations allow you to implement an "algebra" without exposing the
internals of objects.
If you have a distributed system then the distinction of kind 2 and 3
operations becomes important for another reason. Directly accessing
non-local state may not be practical. Some people argue that inheritance
is not useful or even "inconsistent" with distribution. Kind 2 operations
at least makes inheritance "consistent" with distribution. Whether it
is useful can be debated. Still if you drop inheritance from the object
model of a distributed system, operations of kind 3 become important.
For further arguments on this last issue you can read the article on
Emerald in IEEE transactions on software engineering January 1987.
---------------------------------------------------------------------
Anders Bjornerstedt E-mail: anders@cuisun.unige.ch
Centre Universitaire d'Informatique
12 rue du Lac, CH-1207 Geneva
---------------------------------------------------------------------
Tel: 41 (22) 787.65.80-87 Fax: 41 (22) 735.39.05
Home: 41 (22) 735.00.03 Telex: 423 801 UNI CH
---------------------------------------------------------------------
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Re^2: Integrating concurrent & O-O programming
1989-11-23 16:18 ` BJORNERSTEDT Anders
@ 1989-11-26 14:04 ` Markku Sakkinen
0 siblings, 0 replies; 9+ messages in thread
From: Markku Sakkinen @ 1989-11-26 14:04 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~1989-11-26 14:04 UTC | newest]
Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
1989-11-15 19:30 Integrating concurrent & O-O programming Bill Wolfe
1989-11-21 4:09 ` Tim Atkins
1989-11-22 22:08 ` 3929
1989-11-22 22:37 ` Dan Weinreb
1989-11-23 2:52 ` Ziaul Masum Hasan
1989-11-23 9:46 ` Re^2: " NIERSTRASZ Oscar
1989-11-23 16:18 ` BJORNERSTEDT Anders
1989-11-26 14:04 ` Markku Sakkinen
1989-11-23 14:56 ` BJORNERSTEDT Anders
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox