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

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

[John Volan]

milod@netcom.com (John DiCamillo) writes:

>ka@socrates.hr.att.com (Kenneth Almquist) writes:
>>swdecato@cs.nps.navy.mil wrote:
>>> Many Ada folks have demonstrated how Ada objects are created and deleted.
>>> My argument against the Ada style was that I felt that the C++ syntax more
>>> accurately modelled the englist language.
>>
>>I don't know about you, but when I issue a command in English I place the
>>verb before the noun, as in "Mow the lawn."  This translates naturally to
>>the C or Ada code:
>>
>>	mow(lawn);
>>
>>The C++ alternative,
>>
>>	lawn->mow();
>>
>>is backwards.
>
>Actually, your example is backwards.  An imperative in English has
>an implicit subject (usually 'you', that is, the person being commanded)
>and an explicit object (in this case, 'lawn').  So the Ada code would
>be:
>
>  mow(robot, lawn);
>
>and the C++ would be:
>
>  robot.mow(lawn);
>

Actually, in the first C++ example, I'd say that the lawn is the
*subject* of the command, not the *object*!  The trouble here is that,
although C++ is deemed to be "object-oriented" -- it implements inheritance,
polymorphism, dynamic binding, etc. -- nevertheless, its method-calling
syntax is really *subject* oriented!  Let me explain:

If you want to interpret a C++ member-function call such as

	lawn->mow();

as an English imperative sentence, you really have to translate it as:

	"Hey, Mr. Lawn! Go mow yourself! (Uh, no offense. :-)
	(Oh, by the way, mow yourself in whatever fashion is
	appropriate for whatever type of lawn you are.)"

As whimsical and anthropomorphic as this sounds, I seriously believe
that this represents the kind of mindset you need to adopt in order to
program effectively in any language that uses this kind of syntax --
e.g., C++, Smalltalk, Eiffel, etc.  The fact that this sort of thing
sounds so whimsical and counter-intuitive is, in my view, a serious
problem, something which I call "Subject/Object Confusion Syndrome."
The ironic thing is that this confusion only arises because of a
choice of *programming language* syntax, yet, in my experience, it's
resulted no end of difficulties for engineers trying to grasp the
concepts of object-oriented *design*.

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 the example above, we know that we're really telling the computer
to invoke the "mow" function, and the "lawn" object is really an
implied parameter to this function (passed in through the so-called
"this" pointer).  This parameter has some special semantics -- its
run-time type information is used to dynamically dispatch to the
appropriate implementation of "mow" -- but it's still just a
parameter.  However, because of the syntax of the call, we're left
with the impression that it's the lawn that is the subject that is
doing the mowing.

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.  

However, it is very easy to fall into the trap of inventing spurious
"functional" objects, whose only role is to "do" things to your
objects of interest.  For instance, it may seem perfectly reasonable
to argue that lawns don't mow themselves in the real world.  Don't you
need someone or something to actually do the job?   Like, maybe, 
some kind of "robot" object:

>  robot.mow(lawn);

This may sound okay at first: A "robot" object is chunk of software
that knows how to mow a lawn.  When we want a lawn mowed, we'll just
tell a "robot" object to do it.  But in reality this design is
horrible!  The premise was that there are different kinds of lawn that
have to be mowed in different ways.  Does this "robot" object now have
to know about all these different lawn types?  Does it have to do some
kind of switch-statement to discriminate among them?  Or do we now
need to have different classes of robot, one for each type of lawn?
If so, then what's the point of having different lawn classes anyway?
They seem to be just passive data now.  The object-oriented goal of 
encapsulating data and processing together seems to have been lost.

The answer, of course, is that this this "robot" idea just doesn't
work.  The "lawn" object itself is *already* the "thing-that-knows-
how-to-mow-a-lawn."

Contrast this with languages like CLOS or Ada95.  They also implement
inheritance, polymorphism, and dynamic binding, so they are also
deemed "object-oriented."  However, there was no attempt to adopt a
"subject-oriented" method-invoking syntax.  Instead, these languages
took the old, tried-and-true, imperative subprogram-invoking syntax,
and added whatever semantic enhancements were needed in order to
support polymorphic dynamic dispatching.  Consider the Ada95 example:

	Mow (The_Lawn);

Assuming that The_Lawn is a class-wide (polymorphic) tagged-type
variable, this could be translated into an English imperative sentence
as follows:

	"Computer! Go mow the lawn! (Shades of Star Trek? :-)
	(Oh, by the way, mow the lawn in whatever fashion is
	appropriate for whatever class of lawn it is.)"

Here, "the lawn" is the *object* of the sentence -- it is the thing to
which the action of the sentence is directed.  In the corresponding
Ada code, "The_Lawn" is the "object" to which the action of the "Mow"
procedure is directed.  The "subject" perfoming this action is, of
course, the computer itself, just as in every other imperative
programming statement.  In fact, you could view the exclamation 
"Computer!" as an implicit part of every single line of code.

The only difference between this subprogram call and an "ordinary"
subprogram call are semantic differences, not syntactic ones.
"The_Lawn" is a special, polymorphic, "controlling" parameter. It has
a run-time tag that will be used to dynamically dispatch to the
appropriate implementation of Mow.

IMHO, using this traditional imperative syntax is much easier to grasp
than "subject-oriented" syntax.  When used for dynamic dispatching, it
achieves exactly the same semantics as C++'s member-function call.  Yet 
it's much clearer what's "really" going on.  There's no phantom "this"
parameter that you have to know about in order to explain things.

There's still the issue of object-oriented encapsulation:  How do we
convey the fact that the "Mow" procedure is just an integral part of a single
cohesive idea known as the "Lawn" class?  C++ makes it a "member function" of a
class type, with the confusing effect of making it look like a structural
component of every single instance object of that class.  Ada95 uses packaging
to do encapsulation:  We can devote a package to describe the "Lawn" class,
encapsulating within it everything that pertains to lawns, including
an object-oriented (tagged) type and its primitive operations:

	package Lawn is
	  type Object is tagged private;
	  procedure Mow (The_Lawn : in out Lawn.Object);
	  ... other primitive operations ("member functions" in C++)
	private
	  type Object is tagged
	    record
	      ... -- lawn components ("member data" in C++)
	    end record;
	end Lawn;

So, in actuality, a call to the Mow procedure needs to include the package name
as context:

	Lawn.Mow (The_Lawn);  -- assuming The_Lawn is of type Lawn.Object'Class

It's clear that this "Mow" procedure is a modular part of package
Lawn, which encapsulates the *class* of Lawns. "Mow" is *not* a
structural part of The_Lawn *object* that is being passed into it.

Don't confuse this dotted notation with C++'s dotted member notation.
"Lawn.Mow" doesn't mean that "Lawn" is some kind of subject for the
verb "Mow".  The "subject" of the command is still the computer.  If
anything, "Lawn" here could be interpreted as an *adverb* qualifying
the verb "Mow".  All it's indicating is the *scope* in which the Mow
procedure is defined. The closest equivalent to this in C++ is using a
*scope operator*:

	lawn->Lawn::mow();

assuming:

	class Lawn {
	public:
	  void mow ();
	  ... other members
	};

	Lawn lawn;


>>Not to make too big a deal about this--either order (noun before verb or
>>verb before noun) is readable once you get used to it.  I doubt that one
>>order is inherently "better" than the other. 
>
>Agreed.
>
>>However, using both orders
>>in the same program seems like a bad idea if you are concerned about
>>readability.
>
>Oh, no.  Here I must disagree.  The two syntaxes (in C++) represent
>operations with different properties, so having a single syntax is
>potentially confusing.  Note:  I don't believe that the amount of
>confusion in either case is significant, but I am satisfied with the
>C++ (and Eiffel, and Smalltalk, and...) syntax.


I agree that, looking at things mechanically, syntax doesn't really
matter much, because the semantics wind up being the same anyway.  But
I'd say that choice of syntax in a language can have a tremendous
impact on how readily software engineers can internalize good
object-oriented design techniques, without getting confused and
falling into semantic traps.  Sure, if you're a "guru," you can get
used to whimsical things like lawns mowing themselves, or employees
paying themselves their salaries, or enemy missiles engaging and
destroying themselves.  But should every object-oriented software
engineer have to be a "guru" in order to be an effective designer?

Well, that's just some food for thought, I don't really want to start
a language war over this.  Don't mow me down! :-)

				-- John Volan

--------------------------------------------------------------------------------
 Me : Person :=
   (Name => "John G. Volan",  E_Mail_Address => "jgv@swl.msd.ray.com",
    Employer => "Raytheon",   Affiliation => "Enthusiastic member of Team-Ada!",
    Shameless_Controversial_Marketing_Slogan_For_Favorite_Language =>
      "<<<< Ada95: The World's *FIRST* Internationally-Standardized OOPL >>>>" &
      "Inheritance, hierarchical name-space, generic templates, type-safety, " &
      "readability, C/C++/COBOL/FORTRAN interoperability, numeric precision, " &
      "multi-threading, distributed systems, real-time, safety-critical ...  " &
      "<< A d a 9 5  :  Y o u   n a m e   i t ,  i t ' s   i n   t h e r e >>",
    Humorous_Language_Lawyerly_Disclaimer =>
      "These opinions are undefined by my employer, so using them would be "  &
      "totally erroneous ... or would that be a bounded error? :-) ");
--------------------------------------------------------------------------------

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

[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

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

[Maarten Landzaat]

John Volan writes:

>... excellent stuff on why syntactic sugar IS important.

Not many people seem to share this interest in the influence of syntax
on design, readability and other important things.

When I was learning computer science on the university, I always wondered
why I had to say things like

   Show(Window, 33, 45, over_there, graph);

While I could already envision that

   Show my graph in a standard window at position (33,45).

wouldn't be too hard for a computer to translate, especially if I had told him
before that

   Show (object) (how) at position (x,y)

was about to show up somewhere in the program.

I thought that this was a wonderful idea, but no-one seemed to see the
big difference between the two. 

Still I think that ease of use and understandability can make the difference.
Look at the difference between X400 and internet adresses. Look at the
success of PCs after Windows came out, compared to the preceding MSDOS. 


On the same line:

I once mentioned in comp.lang.ada that I found the keyword 'tagged'
a very confusing and non-intuitive way of expressing object-
orientedness. But nobody seemed to mind. I didn't expect that from
people interested in a thoroughly designed language as Ada.


On "robot.mow(the_lawn)":

To my surprise, many projects I've seen that claim to have object 
oriented designs, have 'objects' like Process_Messages, Initialization,
Sender etc. Terrible! It's OK if designs are like this, but calling
them object-oriented is just another way of saying "I don't know what
OO is, and I don't know the difference between a procedure and a
variable". 

Just some thoughts...

-- 
Maarten Landzaat (gijs@mbase97.xs4all.nl)
Amsterdam, Double bass, Fender Jazz Bass, Atari ST, Roland Sound Canvas.
Listen to M-BASE music!

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

[Robb Nebbe]

I took comp.lang.c++ off the distribution list. (If they want to read
interesting posts they can just read comp.lang.ada :-)

In article <D3H7J3.B2x@inmet.camb.inmet.com>, stt@henning.camb.inmet.com (Tucker Taft) writes:
|> 
|> Here is another analogy.  In a normal "dispatching" call, the tag
|> of the controlling parameters determines how the "order" given by
|> the calling task is carried out, but there is no doubt that something
|> will happen.  In a call on a protected object, not only is the
|> interpretation of the call up to the protected object, but whether
|> or not the "order" is carried out at all is up to the protected object.

This doesn't seem quite right. A protected object has no say about which
calls will be executed. It can enforce that it be in a certain state for
a call to take place but this is really no more than a temporal
pre-condition. In contrast a task must explicity accept a call on an
entry and has complete control over such things as the order in which
calls are accepted. A task may also perform actions that are not requested
by someone else, a protected object may not.

I think this is a case where the syntax better represents the
implementation than the semantics. However, I do appreciate that
protected subprograms requiring multiple synchronizations are probably
not "primitve" and is a good enough justification of why the current
syntax was adopted.

|> 
|> Kind of like telling a direct underling to do something, versus
|> "asking" a peer to do something ;-).  "Sorry I'm busy now" is a legitimate
|> answer in the latter case...
|> 

With the cooperative synchronization that exists between tasks this
seems right. I see the competetive synchronization involved with
protected objects as arbitrating the possesion of the object. Thus
multiple peers are competing for the right to tell the protected
object what to do. In John's terminology a protected object can never
be a subject.

Robb Nebbe

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

[John Volan]

bsanden@isse.gmu.edu (Bo I. Sanden) writes:

>For anyone interested in the subject-object relationship especially
>w.r.t. Ada tasking, I respectfully submit that I took exactly that 
>tack (including the term "subject") in my book, "Software Systems 
>Construction with Examples in Ada" (Prentice-Hall 1994). 

Interesting ... I honestly haven't run across your book (yet), else I
certainly would have credited you with coining the term for this, er,
subject. :-)

>Bo Sanden
>George Mason University
>Fairfax, Virginia

--------------------------------------------------------------------------------
 Me : Person :=
   (Name => "John G. Volan",  E_Mail_Address => "jgv@swl.msd.ray.com",
    Employer => "Raytheon",   Affiliation => "Enthusiastic member of Team-Ada!",
    Favorite_Slogan => "Ada95: The World's *FIRST* International-Standard OOPL",
    Humorous_Language_Lawyerly_Disclaimer =>
      "These opinions are undefined by my employer, so using them would be "  &
      "totally erroneous ... or would that be a bounded error? :-) ");
--------------------------------------------------------------------------------

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

[Fergus Henderson]

R_Tim_Coslet@cup.portal.com writes:

>Hmm, just wondering, but has there ever been a computer programming
>language similar in "syntax" to Latin? (using "prefixes"/"suffixes"
>only instead of order to indicate which identifers were refering
>to the procedures/functions and which to data sources or destinations).
>
>Most programming languages seem to use order related syntaxes
>(e.g. prefix, infix, or postfix operator notation)...

Prolog uses case to distinguish between variables (which are data
sources/ destinations) and atoms (which Prolog uses for constants,
functions, and procedures).  Variables must start with an uppercase
letter (or an underscore) while atoms must start with a lowercase
letter (or be quoted).

-- 
Fergus Henderson - fjh@munta.cs.mu.oz.au
all [L] (programming_language(L), L \= "Mercury") => better("Mercury", L) ;-)

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

[John Volan]

dweller@Starbase.NeoSoft.COM (David Weller) writes:
>
>In article <3h1ahp$gf5@gnat.cs.nyu.edu>, Robert Dewar <dewar@cs.nyu.edu> wrote:
>>
>>You are indeed confused. Tagged does NOT "express object orientedness". It
>>merely says that the type contains a runtime tag allowing type extension and
>>polymorphism.
>>
>
>Quite right.  Much in the same way that templates in C++ are not
>explicitly limited to "generic" situations, considering that
>templates are frequently used to implement bounded arrays in a manner
>that would make Ada people giggle.

Dave, 

You're clearly making a slam against C++, but it sounds like you're
also making a slam against Ada in the same breath.  Now, I do agree
with you that C++'s approach to arrays is inferior to Ada array types.
Although a C++ Array template might imitate Ada's constraint checks,
such a template would constitute "user-defined" code and would not be
intrinsic to the language.  Consequently, I seriously doubt whether
there are any C++ compilers that are savvy enough to optimize accesses
to an array the way Ada compilers typically do -- *without* breaking
the safety that Ada-like arrays provide.  For instance, are there C++
compilers out there that can *remove* index-constraint checks when
they can be proven unnecessary, yet retain them when they are needed?

On the other hand, are you also implying that Ada95 tagged types are
in some way inferior as a means of implementing object-oriented
designs?  If so, what do you mean?

--------------------------------------------------------------------------------
 Me : Person :=
   (Name => "John G. Volan",  E_Mail_Address => "jgv@swl.msd.ray.com",
    Employer => "Raytheon",   Affiliation => "Enthusiastic member of Team-Ada!",
    Favorite_Slogan => "Ada95: The World's *FIRST* International-Standard OOPL",
    Humorous_Language_Lawyerly_Disclaimer =>
      "These opinions are undefined by my employer, so using them would be "  &
      "totally erroneous ... or would that be a bounded error? :-) ");
--------------------------------------------------------------------------------

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

[John Volan]

fjh@munta.cs.mu.OZ.AU (Fergus Henderson) writes:

>R_Tim_Coslet@cup.portal.com writes:

>>Hmm, just wondering, but has there ever been a computer programming
>>language similar in "syntax" to Latin? (using "prefixes"/"suffixes"
>>only instead of order to indicate which identifers were refering
>>to the procedures/functions and which to data sources or destinations).
>>
>>Most programming languages seem to use order related syntaxes
>>(e.g. prefix, infix, or postfix operator notation)...

>Prolog uses case to distinguish between variables (which are data
>sources/ destinations) and atoms (which Prolog uses for constants,
>functions, and procedures).  Variables must start with an uppercase
>letter (or an underscore) while atoms must start with a lowercase
>letter (or be quoted).

I think what Tim was referring to was *grammatical* case (think: declension), 
not *typographical* case (think: capitalization).

>-- 
>Fergus Henderson - fjh@munta.cs.mu.oz.au
>all [L] (programming_language(L), L \= "Mercury") => better("Mercury", L) ;-)

--------------------------------------------------------------------------------
 Me : Person :=
   (Name => "John G. Volan",  E_Mail_Address => "jgv@swl.msd.ray.com",
    Employer => "Raytheon",   Affiliation => "Enthusiastic member of Team-Ada!",
    Favorite_Slogan => "Ada95: The World's *FIRST* International-Standard OOPL",
    Humorous_Language_Lawyerly_Disclaimer =>
      "These opinions are undefined by my employer, so using them would be "  &
      "totally erroneous ... or would that be a bounded error? :-) ");
--------------------------------------------------------------------------------

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

[John Volan]

hathawa2@marshall.edu (Mark S. Hathaway) writes:

>There has been some discussion recently on comp.object about the question
>of what mechanism should be used to bring together two (2) or more objects
>to work with and to affect.  I've suggested that in such cases it's always
>better to have such a "higher authority" than to allocate to an object a
>method which doesn't belong.  To have a mow() method in a lawn object seems
>absurd to me.  Since when does a lawn do anything but grow_crab_grass()?

Mark, you've fallen right into one of the prime conceptual traps of
the object-oriented paradigm: You've swallowed the fallacy that
"object-oriented software models the real world."  Despite the
all-too-frequent hype you might have heard, object-oriented software
does *not* model real-world behavior.  Object-oriented software --
like *any* computer software -- is a formalized model of the behavior
we want to elicit out of a *computer*.  Now, there might be a very
compelling *analogy* between objects-in-the-real-world and
objects-in-the-computer, but it's still nothing more than an
*analogy*.  Every analogy eventually breaks down if you push it too
far.  I would submit that the point where the "real-world" analogy
breaks down is precisely when you start trying to deal with behavior.

Definition: A software object is an encapsulation of a *computer's*
responsibilities *with respect to* some real-world object in its
problem domain.  

A software object encapsulates the computer's responsibilities to know
things (data) and to do things (processing) *pertaining to* some
real-world object.  This knowledge and behavior might bear very little
resemblance to the actual knowledge and behavior that the real-world
object itself might be endowed with.  In general, the purpose of
computer software is *not* to mimic what real-world entities do.  In
fact, the whole point is usually to hold the kind of data and to
perform the kind of processing that real-world entities are *not*
already capable of doing. Otherwise why bother programming?

>The authority which mow()s is not the lawn.  

Of course lawns don't mow themselves -- in the real world.  Of course
there's always some "higher authority" or "agent" actually responsible
for mowing a given lawn -- in the real world.  But if we're talking
about the real world, isn't our lawn-mowing *software* a *part* of
the "real world"?  Isn't the program itself that "higher authority" or
"agent" you're seeking?

Of course, our hypothetical program is probably responsible for mowing
a lot of lawns, and for mowing a lot of different *kinds* of lawns,
and for doing a lot of other things to/for/with/about/upon lawns, and
for doing things to/for/with/about/upon a lot of other things besides
lawns.  That's a lot of different responsibilities -- things are
getting pretty complex.  So it would be beneficial if we could to
encapsulate all those responsibilities in a nice compartmentalized
way.

Let's say we take all the responsibilities that pertain just to one
particular lawn of one particular type, and concentrate those
responsibilities into one cohesive software entity, distinct from
everything else in the system.  For simplicity, we might call this
entity a "lawn" object -- but never in our wildest dreams do we
imagine that it's *really* a lawn.  (Last time I looked inside my
workstation, I didn't see any sod on the motherboard. :-) No, a "lawn"
object is really just a particular chunk of our computing resources
that happens to be devoted to managing a lawn.  The only reason we
don't call it a "lawn manager" or a "lawn controller" is that the role
of "managing" or "controlling" is something you can assume about
*every* software object.  That's what software does: it "manages" or
"controls" or at least "keeps track of" things.  So it would be kind
of redundant to tack on that extra verbiage.  It should just be
understood.

Well ... this assumes that programmers actually *understand* what
programming is all about ...

>Create another object which
>can manipulate the mower and lawn objects.  How about...
>
>  class lawn_mowin_fool is
>    -- states:  poverty, drunk, out of control  :-)
>    proc mow ( lawn is in out yard_of_grass; mower is in lawn_mower ) is
>      ...
>    end mow;
>  end lawn_mowin_fool;
>
>  spirit lawn_mowin_fool is
>    proc mow ( lawn is in out yard_of_grass; mower is in lawn_mower );
>  end lawn_mowin_fool;
>
>  proc lawn_care () is
>    obj lmf is lawn_mowin_fool;
>  begin
>    lmf.mow(MyLawn,SearsSpecial);
>  end lawn_care;
>
>This way you can command lmf to mow MyLawn yard_of_grass with a
>SearsSpecial lawn_mower.
>
>Is that decent or what?
>It beats the heck out of asking a lawn to mow itself!

This is silly.  Does our hypothetical program have any
responsibilities that pertain to some real-world "lawn-mowing fools"?
Are there some real human beings out there that the software is
supposed to give orders to, telling them what lawns to mow with what
lawn mowers?  If so, then I suppose I could understand the need for a
"lawn_mowing_fool" class.  

But if the program itself is supposed to control the lawn mowers
*directly*, then inventing a lawn_mowing_fool class is just an
unnecessary complication.  The computer *itself* is supposed to be the
"lawn-mowing fool".  Or perhaps we've already had experience with a
non-computerized system in which "lawn-mowing fools" -- who sometimes
get "drunk" or "out of control" -- are employed to mow lawns.  Perhaps
we're actually trying to *replace* the "lawn-mowing fools" with
software that can do the job better.  If that's case, then imitating the
behavior of "lawn-mowing fools" in software would be not be "cool" or
"decent" -- it would be totally *foolish*. :-)

The point of this thread was that when you see a C++ member-function
call like:

    theFrontLawn.mowWith(theSearsSpecialMower);

or a Smalltalk method call like:

    theFrontLawn mowWith: theSearsSpecialMower.

you should never feel complled to imagine this as meaning "the front
lawn will mow itself using the Sears Special lawn mower".
Unfortunately, the syntax seems to encourage this kind of
interpretation, and a lot of people even *advocate* this kind of
thinking as being "cool".  However, I (today) believe this is a silly
way of interpreting what object-oriented software does.  Instead, I'd
read this kind of call as meaning "the part of the computer devoted to
the front lawn will mow it (the front lawn) using the Sears Special
lawn mower."  You always have to keep in mind that "theFrontLawn" is
just a chunk of *software* responsible for the front lawn -- and I
think "mowing the lawn" should be an integral part of its
responsibilities, not something off-loaded to another object.

The equivalent call in Ada95 might be something like:

    Lawns.Mow (The_Lawn   => The_Front_Lawn,
               With_Mower => The_Sears_Special_Mower);

(assuming "Lawns" is a package containing a tagged type "Lawn" with a
primitive procedure "Mow"). With this syntax, I'd wager you'd be much
less likely to view "The_Front_Lawn" as somehow "mowing itself".  Yet
this Ada subprogram-call might have exactly the same dynamic-
dispatching semantics as the C++ member function call or the Smalltalk
method invocation above.  That is, "The_Front_Lawn" might be a special
"controlling" parameter, whose run-time type information ("tag" in
Ada95 jargon) would determine which overloaded implementation of "Mow"
to dispatch to.

 >Mark S. Hathaway       <hathawa2@marshall.edu>

--------------------------------------------------------------------------------
 Me : Person :=
   (Name => "John G. Volan",  E_Mail_Address => "jgv@swl.msd.ray.com",
    Employer => "Raytheon",   Affiliation => "Enthusiastic member of Team-Ada!",
    Shameless_Controversial_Marketing_Slogan_For_Favorite_Language =>
      "<<<< Ada95: The World's *FIRST* Internationally-Standardized OOPL >>>>" &
      "Inheritance, hierarchical name-space, generic templates, type-safety, " &
      "readability, C/C++/COBOL/FORTRAN interoperability, numeric precision, " &
      "multi-threading, distributed systems, real-time, safety-critical ...  " &
      "<< A d a 9 5  :  Y o u   n a m e   i t ,  i t ' s   i n   t h e r e >>",
    Humorous_Language_Lawyerly_Disclaimer =>
      "These opinions are undefined by my employer, so using them would be "  &
      "totally erroneous ... or would that be a bounded error? :-) ");
--------------------------------------------------------------------------------

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

[David Weller]

In article <D3MwqH.LDL@swlvx2.msd.ray.com>,
John Volan <jgv@swl.msd.ray.com> wrote:
>dweller@Starbase.NeoSoft.COM (David Weller) writes:
>>Quite right.  Much in the same way that templates in C++ are not
>>explicitly limited to "generic" situations, considering that
>>templates are frequently used to implement bounded arrays in a manner
>>that would make Ada people giggle.
>
>the safety that Ada-like arrays provide.  For instance, are there C++
>compilers out there that can *remove* index-constraint checks when
>they can be proven unnecessary, yet retain them when they are needed?
>
Hmm, this should be crossposted, but I think CodeCenter does.  It's
been a while now.  You see, I've been "C++ Free" since August, 1994
:-)

>On the other hand, are you also implying that Ada95 tagged types are
>in some way inferior as a means of implementing object-oriented
>designs?  If so, what do you mean?
>
Not quite.  What I was saying was that I agreed with Dewar's original
comment -- tagged types do _not_ imply they are limited to
inheritance.  There's some extra goodies you get out of using tagged
types that go past things like inheritance (RTTI, for instance).
What I was _really_ trying to say is that tagged types exhibit the
same philosophical flexibility as templates in C++ (or anything else
you'd like to creatively do a #define on :-)

-- 
      Frustrated with C, C++, Pascal, Fortran?  Ada95 _might_ be for you!
	  For all sorts of interesting Ada95 tidbits, run the command:
"finger dweller@starbase.neosoft.com | more" (or e-mail with "finger" as subj.)
	

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

[Mike Bates]

R_Tim_Coslet@cup.portal.com writes:

>Hmm, just wondering, but has there ever been a computer programming
>language similar in "syntax" to Latin? (using "prefixes"/"suffixes"
>only instead of order to indicate which identifers were refering
>to the procedures/functions and which to data sources or destinations).
>
>Most programming languages seem to use order related syntaxes
>(e.g. prefix, infix, or postfix operator notation)...

Yes!  Replace while loops with the ablative absolute!

grassibus.longibus {
  lawnum.mowite;
}

(Sorry, my Latin dictionary is at home.)


-- 
------------------------------------------------------------------------------
Mike Bates               FlightSafety International, Simulation Systems Div.
Principal Engineer       2700 North Hemlock Circle
Computer Systems Group   Broken Arrow, Oklahoma 74012
mikeb@ssd.fsi.com        918-251-0500 ext. 462
------------------------------------------------------------------------------

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

[Jules]

In article <9503802.3538@mulga.cs.mu.oz.au>,
	fjh@munta.cs.mu.OZ.AU (Fergus Henderson) writes:

>all [L] (programming_language(L), L \= "Mercury") => better("Mercury", L) ;-)

Doesn't this mean that all programming languages (other than Mercury) are
better than Mercury? ;->

-- 
/* Julian R Hall				csusb@csv.warwick.ac.uk
   
   Flames should be redirected to /dev/null - I don't know what
   I'm saying myself so don't expect it to make sense all the time!         */