From: Bob Hathaway <objsys@netcom.com>
Subject: Re: Type Conformance and Inheritance (was O.M() versus M(O) notation)
Date: Thu, 20 Aug 92 02:27:05 GMT
Organization: Object Systems

In article <KERS.92Aug19111407@cdollin.hpl.hp.com>, kers@hplb.hpl.hp.com (Chris Dollin) writes:
>| One, grammar is important since it defines our interface with a programming
>| language.  If a natural grammar is used then software engineers (as long
>| as they're people) will have an easier time of it; simple ergonomics.
>| And grammar is used to hang semantics on and works like a guide to make
>| things easier to understand.
>
>That's true, but it works in the other direction; you *pick* a grammar to make
>the *concepts* clear in the language, rather than picking up some grammar
>that's been lying around like a dirty sock and trying to fit it onto your
>hands.

I'm surprised you refer to our programming language's English heritage that
way; maybe you prefer Lisp:-)  Lets not get into this argument again but
everyone knows English (excepts maybe the French (ha ha, just kidding))
and it therefore comes most naturally to us; hence our languages gramatical
bias towards the imperative invocation.

>| And the assymetry is not irrevelevant.  Since an object exists with an
>| interface of available operations (and whatever) this is very important.
>
>That's if you *assume* that the objects exists with the interface (etc). It's
>not a given, it's a choice.

Not really.  The real world is made up of objects and they do possess
properties and attributes and etc.  Current object-oriented techniques
simply use a behavioural (or observational) approach to defining these
object's externally visible interface to the world.  Analyze any process
and you'll find a set of objects interacting with each other.  This occurs
at all levels in the real world.  I don't see how this is questionable, it
is an objective fact.  Do you really dispute this?

Anyway, there are many ways of viewing this objective reality.  I'll
admit this may be disputable.  All object-oriented texts justify a view
based on the real world, try Booch OO Design or Rumbaugh et al OO Modeling
and Design for some examples and for a jillian reasons why.

>...
>In the software reality, M can certainly be the doer; consider CLOS, for
>example, with generic functions rather than objects-that-know-how-to.
>
>In physical reality, doers are not "sent messages" that tell them how to
>change their state. 

Yes they do.  "Bob, go to the store" is a request for an action.  And doers
don't just change state, they can perform actions or even just think about
things although you might refer to the latter as a state change (but I still
don't like connectionists (just kidding :-)) and they are usually quite
capable of inciting their own actions.  The imperative of making requests
and issuing commands is ubiquitous, so I dispute the logic of your above
statement.

>                     Even the normal (English grammar) notions distinguish the
>doer (which performs the action) from the done-to (which suffers it).

The many examples, such as the imperative request for me to go to the store,
show this not to make sense so again I'll have to dispute your logic and ask
for an elaboration.

>|...
>|This is jibberish.
>
>Thank you for your kind words.

Sorry, my car's in the shop, the computer was degraded worse than I've
ever seen it, and the person who lent me their car called and said to
hurry home since they needed it right away; all while I was responding
of course.

>| There are stacks in the real world and there are abstract stacks in
>| artificial worlds.  They have certain attributes and properties and can
>| perform certain operations *by thier very nature*.
>
>That's one way of describing the situation, yes. But it's not a matter of
>natural law; it's a matter of how you choose to *describe* stacks. Certain
>things happen, and certain relationships hold. Attributing control to one or
>the other "thing" in the description is a matter of *choice* -- you choose the
>description that seems best fitted to your needs.

Scarce aggreement if any on this from me.  You are an object, the pencil on
my desk is an object, and so on.  These are not subjective views, you and the
pencil have definite properties and attributes which work over you as a whole.
Do you have a better point of view.  The functional one seems even further
from reality to me but I do keep an open mind.  Do you have a convincing
argument that there is a better and more natural way of viewing the world?
I'm all ears.

>Now, certainly the choice is not *arbitrary* -- it's nice if the description
>is internally consistent, nicer if it also describes the kinds of things that
>you want it to describe. But that doesn't mean that there's only one choice.

Again, if I can show an objective reality such as: the universe is made up
of objects and these objects have properties and attributes that are
objectively discernable, measurable, and workable then there is only
one objective, true description.

>I've just ``give my cup a little push''. (I was taling to someone about
>actions as objects, and how real they were, and this piece of idomatic English
>just popped out.) It suggests that actions can be -- are -- objectified in
>(some) natural language uses. Are they still not in the real world?

No, they are not.  You as an object can push the cup.  If you design an
artificial reality and can say ``give my cup a little push'' and it moves
a little this is magic, not metaphor.  In our minds we have a notion of push
but it is based on all the ways all the different kinds of objects that can
push other objects.  There must be a pusher and almost always a pushee for
push to work because this is the way it works in reality.

>| In other words, there aren't little "pushes" floating around but there are
>| stacks that one can push an object onto.
>
>Your stack is just as much an abstraction as my push. Stacks don't come with
>little labels saying "I am a stack" (although I suppose that they would if
>they were International Rescue equipment); we call them stacks because they
>relate in a particular way to the rest of the world.

But there are stacks in the real world and there are not "pushes".

>| It is clearly an operation by nature, it doesn't matter if you call it
>| "push" or even if you don't call it anything at all, a stack is still a
>| stack and can perform the operation!
>
>Oddly enough, the stacks I know of in ``real life'', the archetypal push-down
>stack of restaurant trays, are incapable of pushing objects -- something else
>has to do the pushing.

Then you know how to push the tray.  I think you're arguing either the
behavioral interface approach or the choice of interface.  If you want the
stack to be more like the stack you're referring to then make it an aggregate
of movable parts and then define the spatial relationships and dynamics of
the system; it'll work just fine.  Your argument sounds like a choice of
interface argument; the behavioral interface can be viewed as merely a
simplification or abstraction of the real physical system involved.  And
the aggregate parts do have properties and characteristics, too.  They should
be part of their interface to the world and not separated as with the 
unencapsulated approach.

>|   Bob, go to the store.
>|   Stack, push this tray.
>|
>| Actually in RWMing:  Bob, put this on the stack.  Stack, push this object.
>|
>| The doer is clearly defined in the most natural way known to us.  If
>| there is no object (entity or whatever) which is to explicitly carry out
>| this command, then we could have:
>
>Now you are applying the terms of our world model (with intelligent agents
>[which, I suspect, is a model we share, irrespective of its truth]) to
>software concepts (``objects'') in a way you need to convince me is
>well-founded.

With VR this is trivial.  Most other software domains also deal with or
describe real world entities and therefore modeling these entities is the
most important issue involved.  Also please be careful with the term
"world model".  In AI this is the model or context in your head and I
don't think this is the way you're using it.

>I don't need any references to reality. I have one here now :-)

True, that is why OO and OO systems are so trivial to build.  Even better
with AI.

>Reality is more slippery than you seem to think. My analysis would have
>``bearing on reality'' if it let me make (testable) predicictions about
>reality that were (by and large) true. (``By and large'' because the world is
>far too big for any computer model we build to catch everything.

I don't see this.  I can break the real world up into objects even starting
with atoms, subatomic particles, and quarks, and can work my way up to any
object that has discernable properties, can you do so for your model?

> Probably no
>model contained *in* the world can model *all* the world.)

Interesting claim, can you prove it?

>| And from an SE point of view, there will be others who must understand your
>| design. If the design is close to reality, everyone capable of dealing with
>| reality will understand it.
>
>Of course the design has failed if no-one else has understood it -- but so
>what? That's just true about design. It means that designs must be
>comprehensible. This is true for OO designs, functional designs, JSP designs,
>or Kers's Patented Automagical Analyses.

You missed the point.  It is that if it is natural, then its more likely that
someone else can understand it.  Its like what you said below but since
there's no argument, I'll delete it.

>| If it is not based on reality, the "object concept" decrees that
>| structuring the system into objects is an excellent way of designing systems
>| anyway.
>
>It's certainly *a* way. It might (or might not) be an *excellent* way. But
>it's not the *only* way, and it might not be the only *excellent* way. Decrees
>do not establish truth.

Actually, there's an incredible building amount of evidence that OO systems
are more maintainable, hold up better over time, are easier to understand,
etc.  Its the old style unencapsulated approach that seems to have failed
miserably (the software crisis), no?  

|>   If this isn't so clear, then go imperative without an explicit receiver of
|>   M.
|>
|>By which I presume mean ``try the symmetic notation''.
|
| Sure.  If all else fails, let the computer do it (the implied imperative
| you)?  This sounds like punting to me.

>I don't understand what you mean, then. If we're talking about programs ``the
>computer'' does *all* [modulo trivia about I/O handling, etc] the doing -- the
>"objects" are simulated by the machine. Well, if it can simulate objects, it
>can simulate operations, too, and all that describing this as "punting" does
>is to say that you don't like it [and cast aspersions on one of Oxfords most
>enjoyable activites, to boot].

No.  In OO programs the objects carry out the operations; the computer is
transparent.  This is not so with your model.

Also, if I write an imperative algorithm without an explicit doer, such as:
  take this
  do that with it
  put this here
  do that
  you're done

There is the implicit imperative you for each instruction.  If I now reuse
this component by following it myself, handing it to a robot to perform, or
whatever then self becomes the implicit receiver.  In OO any such imperatives
are considered with an implicit self making this algorithm *completely
reusable*.  It can be used by any actor (object).  If anyone else needs to
carry out an operation in the algorithm, the algorithm can specify that also
with O.M....  Notice that makes the receiver special (which it should be
anyway) and by not including it as a parameter WE HAVE A BETTER MODEL with
the O.M ... or even (O).M ... (implied receiver).  Again, discerning the
doer is more clear AND more reuasable AND closer to reality.  Don't get
this without discerning the receiver, huh?

It even carries over to multiple receivers: 

   Bob, Mary, Carrie, go to the store.

In such cases, each should receive the command.

>Perhaps I have mis-spoken; the messages are not the receivers, they are the
>doers. You seem to be refusing to take actions as objects; well, that's a
>choice. It may be a convenient and frutiful choice; well and good. That

No, it has a bearing on reality since the objects in the artificial world
are the actors, the computer is transparent.  This matches reality,
your approach doesn't.

>doesn't make it the *only* choice, and I read your arguments as saying
>``object orientation is not only useful, it's *right*''.

But it matches reality.  If you have a better way of modeling and or
simulating it speak up.  This functional orientation just seems much
further from the truth.

>In the presence of multi-methods, why should one argument to a message send
>have a special syntactic position?

Because it is the object performing some action, as is always the case in
the real world.

|>   I can't make sense of it.
|>
|>Of multi-methods or of the discussion so far?
|
| Of his use of the expression "overloading on the first parameter".
| Anyone not overloading on all parameters dynamically should be proverbially
| shot.  I am quite knowledgeable on the rest, thank you.

>Well, "normal" OO languages (Smalltalk, C++, Simula) *do* only ``overload on
>the first parameter'' -- that is, the action that is performed is determined
>by the "message" and the (type of the) first parameter (the receiver), which
>may in consequence be granted special syntactic status.

Smalltalk does so because it is statically typeless and C++ is statically
typed.  I consider both weak because of this.  And I'm not up on my
Simula.  The languages here obviously have O.M... notation and use
multi-methods, they always have.

>Granted, the selected action may then perform further dispatch, if that's what
>the programmer has written. But that's not something the language does *for*
>you, whereas in CLOS the action is determined by the "message" (the generic
>function) and, in principle,  (the types of) *all* the parameters.

This is based on weak or contrived systems.

>It's so obvious -- and it isn't true. Yes, it's obvious, and we [humans; I'd
>not like to speak for the rest of the biosphere] are probably engineered to
>see it that way. It's certainly a handy way to carve up the world, and it
>works pretty well.

No, I've declared it as an objective fact and have yet to see otherwise.

>It works *so* well that we try to make things into objects at the least
>provocation. Is a classroom an object? How about a university? A nation? A
>solar system? A galaxy? A flock of birds? A river? A photon? A traffic jam? An
>ozone hole? A county boundary? A code? A (real) window? An (X) window? The
>*law* of gravity? The *force* of gravity? Magnetism? The aether? A
>(mathematical) group?

First, try your hand at virtual reality.  That will answer your question.
If you don't base everything on objects you're a fool.  And the rest of
these examples are mostly concepts and abstractions like the kind we work
with *in our heads*.  Yes, we can give attributes to a flock of birds
even if thats not the way the real world is broken up.  This is the
subjective side, not the objective side of objects.  For my own purposes
I've broken the world up into transitory parts such as real-world modeling
(RWM), mental worlds (MW), and abstract worlds (AW) since each has its own
requirments and properties.  For RWMing its OO all the way and for the rest
the same applies.

>What sends messages to a mass to tell it to exert force on the floor?

The universe enforces universal laws in my book.

>What sends messages to ``1'' in ``1 + 2'' to tell it to compute ``3''?

Define the ring of integers and export its operations (like Ada's use clause).

>Do I send messages to my cup when I fill it with tea? 

It does know something has come in contact with it.  I like the universe
idea myself for "dumb" objects and forces.

>Is the object-oriented notion of "message" appropriate to cups, tea-bags,
>waves (wet), waves (electo-magnetic),

If it comes in contact, sure.  Physical dynamics are handled by the
universe with objects at various levels receiving the various forces.
It gets more interesting with us because our senses input these forces
on contact and then interprets them using trellises and other wonderful
things.  I'd love to go on but my time's up and way past due.  

[Bragging on]  I did know about the nature of event-driven inputs by contact
before reading about them and about many other wonderful things too, so
I'm sure I'm not going to be easy to live with in this discussion (and
perhaps many others) but please try to bear with me anyway!!!-)
[Bragging off]

bob
objsys@netcom.com
Newsgroups: comp.object