NetNews Usenet Archive 1992 #18/NN_1992_18.iso/spool/comp/object/3256

Internet Message Format | 1992-08-19 | 14.8 KB

From: [e-mail] (Chris Dollin)
Date: Wed, 19 Aug 1992 10:14:07 GMT
Subject: Re: Re: Type Conformance and Inheritance (was O.M() versus M(O) notation)
Message-ID: <[e-mail]>
Organization: Hewlett-Packard Laboratories, Bristol, UK.
Path: sparky!uunet!van-bc!rsoft!agate!ames!sun-barr!cs.utexas.edu!sdd.hp.com!hpscdc!hplextra!otter.hpl.hp.com!hpltoad!cdollin!kers
Newsgroups: comp.object
References: <[e-mail]> <[e-mail]> <=!![e-mail]>
Sender: [e-mail] (Usenet News Administrator)
Lines: 307
In-Reply-To: [e-mail]'s message of 19 Aug 92 01:09:44 GMT
Nntp-Posting-Host: cdollin.hpl.hp.com


In some article, [e-mail] (Bob Hathaway) writes:

|>I don't see what the grammatical status of an object has to do with anything.
|>Surely we're discussing *meaning*, not *notation*, here, and PGs point is
|>exactly that the asymmetry of the O.M(...) notation *encourages* a
|>corresponding but irrelevant semantic asymmetry.
|
| 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.

| 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.

|>   is imperative (with an IE,) showing clearly the Object (O) to be the
|>   receiver (or doer) of the command (M) and parameters to be objects.
|>
|>I think it's M that's the "doer" and O,(...) are the parameters.
|
| But this has no bearing on reality, something which we are used to dealing
| with and can naturally solve problems in and can comprehend well.

I disagree.

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. Even the normal (English grammar) notions distinguish the
doer (which performs the action) from the done-to (which suffers it).

| We form an "object concept" early on.  The world is made up of objects
| and we are quite good at working with them.

See below for my diasgreement.

|>   A stack has a push "action" so the stack is the doer of the action and
|>   making this explicit should help.
|>
|>But this is just one interpretation, right? Stacks don't "have" push
|>actions as a matter of Natural Law; it's just one way of carving the
|>computational cake.  We can just as well say that pushes "have" stack
|>variants.
|
|This is jibberish.

Thank you for your kind words.

| 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.

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.

| A type can easily capture these properties.

Trivially true, as that's what types are *for* -- we wouldn't call them types
if they didn't do that.

| This is based on an understanding of the real world, again something we deal
| with quite well and as any object-oriented software engineer can tell you
| has been found to be an excellent (if not the best) way for us to solve
| problems.

The real world is a lot bigger than you seem to be implying -- see later.

| There is no "push" in the real world, this only exists in our heads
| subjectively and is something quite contrived.

Your choice.

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?

| 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.

| 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.

|>Now, in the case of stacks and pushes, the stack *changes* [assuming we're in
|>an imperative context; in something like Haskell or Axis, the push just gets
|>you a new stack, and nothing changes, not ever, not even a bit.]. You could
|>chose to indetify the "doer" with the thing subject to change ("objects know
|>how to do things to themselves"). An odd model, this, when normally one
|>expects the doer to be the one *not* suffering the effect!
|
| Please read up on the imperative sentence.  Here is a simple example:

I am aware of the meaning of ``imperative'' in both the natural-language and
programming-language sense (which is derived from the NL sense).

|   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.

|   move_element from stack a to stack b
|
| But who carries this out?  The computer?  If we want anything based on
| reality (and I'll be disappointed if I need to supply references) then maybe

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

|   bob, move_element from stack a to stack b.
|
| Or if I'm not around, then maybe:
|
|   stack_mover, move_element from stack a to stack b.
|
|> Also, if several objects (parameters) are affected, this criterion breaks
|> down. What about moving an object from one stack to another? Why should the
|> move "message" be sent to one of them, rather than the other? You may argue
|> that "move" isn't a real primitive on stacks, but who are you to argue with
|> my analysis of a problem domain? [Perhaps I shouldn't call them "stacks",
|> but the point remains.]
|
| I can argue with your analysis on the basis that it has no bearing on
| reality but is rather based on some subjectively contrived system that
| you may prefer, but how do you justify that anyone else will?

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. Probably no
model contained *in* the world can model *all* the world.)

| 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.

What does ``close to reality'' mean? It means that it employs concepts
familiar to those who work in the real world -- not just *anyone*, of course,
because their are different conceptual breakdowns one can make of the world.
If the design is couched in terms familiar to other designers, then they can
use it.

[The if-then in your text is in fact false, unless it's definitional. Let us
take QM and GR as being ``close to reality''. I bloody well don't understand
them. Is that because they're not object-oriented?]

| 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.

|>   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].

|>   If it is, you're obfuscating the reciever which will be to the detriment
|>    of understanding.
|>
|>Well, the second part follows from the first, because of the meaning of
|>``obfuscation'', but I don't think it's true that one is obf. the receiver,
|>because I think the receiver is the message [at least for the purposes of
|>this note].
|
| As pointed out before, messages as receivers have no bearing on reality,
| do you have a counter example?

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
doesn't make it the *only* choice, and I read your arguments as saying
``object orientation is not only useful, it's *right*''.

|>  Also, whats with this "only overloading on the first parameter" stuff?
|>  Have you heard of multi-methods or more simply "dynamic method selection"?
|>
|>Surely this is the point of PGs postings; given multi-methods, why on earth
|>should the invocation syntax specially distinguish one object out of the
|>several supplied?
|
| You're thinking of CLOS, multi-methods are just "dynamic method selection"
| in the context of functions or methods where static and dynamic types are
| present.  Just read Coplien, Advanced C++... for at least one such usage.

I *have* read Coplien, thank you. But that doesn't answer the question. I
could just as well say "dynamic method selection" is ``just'' multi-methods.

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

|>   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.

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.

So I think that's what PGs expression means.

|>Remember, The Real World Is Not Object-Oriented.
|
| Yes it is.  The real world is obviously made up of objects, this statement
| is non sequitur.  Its the function-orientation that has no real-world
| basis, its based soley on artificial formal (and hence extremely weak)
| 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.

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?

What sends messages to a mass to tell it to exert force on the floor? What
sends messages to ``1'' in ``1 + 2'' to tell it to compute ``3''? Do I send
messages to my cup when I fill it with tea? Is the object-oriented notion of
"message" appropriate to cups, tea-bags, waves (wet), waves (electo-magnetic),
potentials, colours, warmth, cogitation, dreaming, writing, swimming,
painting, the smell of fresh roses, the Dance of the Sugar-Plum Fairy, Annie
Haslem's voice-without-words at the end of Ashes Are Burning, or the way may
car holds together when at rest? Is Shakespeare's ``Macbeth'' an object? Is
Macbeth (an enactment) an object? Is Macbeth (himself) an object?

The world is grossly under-described by the kinds of ``objects'' we seek to
exploit in the object-oriented style of programming. I'll not deny that the
world *has* objects [by which I mean that the concept is enormously useful for
day-to-day living, and allows us to make predications about how the world
will behave]. But they are but *one* way of describing the world, not the
*only* way, and to restrict oneself to that one style is to impoverish
both the world and oneself.

Now, in an OO program (or, for that matter, in an OO analysis), one might
*model* some of these things as ``objects''. But that doesn't mean they *are*
objects -- whatever "is" means.
--

Regards,    | ``In fingers of trees, and valleys of gold    | Judy Tzuke
Kers.       | I watch as you outshine the charlatan foe.''  | Higher & Higher