From: Bob Hathaway <objsys@netcom.com>
Subject: Re: Type Conformance and Inheritance (was O.M() versus M(O) notation)
Date: Wed, 19 Aug 92 01:09:44 GMT
Organization: Object Systems

[Hi Chris, I recall our previous (about 1 year ago) ongoing debate about
dropping the hierarchical restriction from the module/package construct,
I believe you wanted to use generics instead?  Anyway, I didn't have
time to follow thru (it wasn't a lack of interest) so perhaps we could
pick up the discussion again.  Anyway, on with the new...]

In article <KERS.92Aug18110434@cdollin.hpl.hp.com>, kers@hplb.hpl.hp.com (Chris Dollin) writes:
>In article ... Bob Hathaway <objsys@netcom.com> writes:
>   No it is not.  There is nothing symmetrical about pushing an element onto
>   a stack since the two objects are not equal gramatically.  O.M ...
>
>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.

And the assymetry is not irrevelevant.  Since an object exists with an
interface of available operations (and whatever) this is very important.

>   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.
We form an "object concept" early on.  The world is made up of objects
and we are quite good at working with them.

>   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.  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*.  A type can easily
capture these properties.  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.  There is no "push" in the real world,
this only exists in our heads subjectively and is something quite contrived.
In other words, there aren't little "pushes" floating around but there are
stacks that one can push an object onto.  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!

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

  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:

  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

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

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

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

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

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

bob
objsys@netcom.com
Newsgroups: comp.object