Re: Subject/Object Confusion Syndrome [was: Ada Objects Help]

[ncohen@watson.ibm.com (Norman H. Cohen)]

In article <D38q48.3yM@swlvx2.msd.ray.com>, jgv@swl.msd.ray.com (John Volan)
writes: 

|> Every computer program has responsibilities to perform certain actions
|> and computations with respect to the "objects" in its problem domain.
|> A good object-oriented design will take all the responsibilities that
|> pertain to a given class of real-world objects and encapsulate them
|> into a single, cohesive software module.  But in order to render that
|> into a programming language that uses this "subject-oriented" syntax,
|> you have to imagine that the objects *themselves* are responsible for
|> the actions that the computer has to "do" to them.  Now, we all know
|> that it's really the *computer* that's going to "do" these things --
|> in other words, the computer is really the "subject" of our program's
|> imperative commands.  However, because of the syntax involved, you
|> have to pretend that it's actually the "objects" that are the
|> "subjects" of these commands.
...
|>
|> In my experience, this confusion between "subject" and "object" is the
|> single most difficult conceptual hurdle you have to overcome in order
|> to master the object-oriented paradigm, whenever you work in languages
|> like C++ or Smalltalk.  Because of this confusion, it can be difficult
|> at times to decide where a certain responsibility should go.  For instance,
|> in deciding which object should have the responsibility to "mow", you
|> have to keep remind yourself that the "lawn" object is not really the
|> "lawn" itself.  It's just the "part-of-the-computer-responsible-for-doing-
|> things-to-the-lawn" -- including, perhaps, mowing it.

Thanks for an insightful analysis, which goes right to the heart of the
dispute between advocates of the

   object.operation(...)

and

   operation(object,...)

notations.

While these observations argue against the object.operation(...) notation
in C++, they do not apply to a language like Actors, where objects are
truly active.  Ada tasks are also active objects, and John's discussion
explains the indecision I've often had naming entries of Ada tasks.
Where John thinks in terms of the "computer" having responsibility to
perform certain actions, I think in terms of tasks having those
responsibilities (including the environment task that executes the main
subprogram of a single-task program); I think of procedure calls as
imperatives addressed to a task.  But when a rendezvous is to take place
so that a sender task can notify a recipient task that some event has
taken place, it is not clear whether the entry call should read as an
imperative addressed to the calling task--

 Recipient.Notify_Of_Event; -- Yo, Sender! Notify Recipient of the event!

--or the called task--

 Recipient.Note_Event; -- Yo, Recipient! Note that an event has occurred!

In John's terms, should the task name in an entry call be the subject or
the object?

(By the way, I also think the object.operation(...) notation is
justifiable for a language like Self, where different standalone objects
of the same class can have different methods.  Such methods really are
members, hardly distinguishable from data members.  My objection to the
use of this notation in C++ is that it gives the impression that
different objects in the class each have their own member functions when
in fact they all have the same function.  C++ is pretending to support a
paradigm that it does not support in earnest, the way Self does.)

--
Norman H. Cohen    ncohen@watson.ibm.com