Meyer 93

Systematic Concurrent Object-Oriented Programming
by Bertrand Meyer (Note:
 OOSC)
in Communications of the ACM
September 1993, Vol 36, No. 9
pp 56-80

p 56
What is the simplest, smallest and most convincing extension to the
method of systematic object-oriented software construction that can
address the needs of concurrent and distributed computing as well as
those of sequential computation?

Provability, p 60
The smallest permissible level of granularity for exclusive access to
an object is the execution of a call to an exported feature.

Support for Command-Query distinction, p 60
The command-query distinction directs programmers to refrain from
using a programming style that has become popular in recent years
[...]: functions that produce visible side-effects. This practice
endangers referential transparency (substitutivity of equal for
equals).

Function *item*, a query [...]
Procedure *remove*, a command [...]
A designer who does not apply the command-query distinction might be
tempted to replace these routines by a side-effect producing function
*get* [...]

No Active-Passive Distinction, p 62
The present discussion differs from [most current] approaches by
refusing to include an explicit notion of process or of active object.

This is the starting point of object orientation: the realization that
you can almost always do more than one thing with an object. This
refusal to consider any one feature as "the main operation" on a class
is one of the main tenets of the object-oriented method, and yields
some of its key advantages in terms of software extendibility and
reusability.

Processors, p 63
Computation, [...] involves three elements: certain processors apply
certain actions to certain objects.

In ordinary sequential computation, there is only one processor, which
is why it tends to remain implicit.

It is important to note that this notion of processor is virtual
[...].

Citation from [Lieberman]:
The number of [processors] need not be bounded in advance [...].

To avoid any confusion, the present discussion will employ the term
"processor" only in this sense of virtual thread of control.

Separate Entities, p 64
Any concurrent semantics we choose will imply that *t.f. (...)* may
have a different effect depending on whether the object attached to
*t* is handled by the same processor as the client or by a different
one. It would be unacceptable to hide this important difference from
the reader of the software text.

[...] the semantics are different. In addition to the change in the
interpretation of assertions, there is an even more fundamental
difference: execution by the same processor is blocking [...].

Semantics of Assertions, p 65
What then should the semantics of a precondition [...] be if the
client and supplier are handled by different processors? Only two
answers seem to make sense:
- [...] the exception semantics.
- [...] the waiting semantics.

Reserving Objects, p 66

[Lieberman]
Lieberman, H.
Concurrent object-oriented programming in Act 1.
In Object-oriented Concurrent Programming,
Akinori Yonezawa and Mario Tokoro, Eds.
MIT Press, Cambridge Mass., 1987, pp 9-36