From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-0.3 required=5.0 tests=BAYES_00, REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 109fba,c890e6ab3fb2c5fc X-Google-Attributes: gid109fba,public X-Google-Thread: 103376,c890e6ab3fb2c5fc X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 1995-02-01 06:33:47 PST Path: nntp.gmd.de!Germany.EU.net!wizard.pn.com!satisfied.elf.com!news.mathworks.com!newshost.marcam.com!zip.eecs.umich.edu!newsxfer.itd.umich.edu!gatech!newsfeed.pitt.edu!uunet!newsgate.watson.ibm.com!watnews.watson.ibm.com!ncohen From: ncohen@watson.ibm.com (Norman H. Cohen) Newsgroups: comp.lang.ada,comp.lang.c++ Subject: Re: Subject/Object Confusion Syndrome [was: Ada Objects Help] Date: 1 Feb 1995 14:33:47 GMT Organization: IBM T.J. Watson Research Center Distribution: world Message-ID: <3go64b$m4u@watnews1.watson.ibm.com> References: <3f9g1u$j4m@nps.navy.mil> <3fu6qc$pc5@gnat.cs.nyu.edu> <3g3uc0$hm6@watnews1.watson.ibm.com> <3g49bu$7fv@nps.navy.mil> Reply-To: ncohen@watson.ibm.com NNTP-Posting-Host: rios8.watson.ibm.com Xref: nntp.gmd.de comp.lang.ada:18439 comp.lang.c++:88504 Date: 1995-02-01T14:33:47+00:00 List-Id: In article , 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