From: objsys@netcom.com (Bob Hathaway)
Newsgroups: comp.object
Subject: Re: O.M(...) vs M(...), and is the Real World O-O?
Summary: #2
Date: 1 Sep 92 22:51:39 GMT
Organization: Object Systems


[I think we've beaten these subjects to death and I unfortunately don't have
the time for these long replies.  I'll just wrap-up and let us try to get
on with things.  Perhaps a wrap-up from Chris would be nice too]

In article <KERS.92Aug26181137@cdollin.hpl.hp.com>, kers@hplb.hpl.hp.com (Chris Dollin) writes:
[On multi-methods]

The term "multi-methods" stands for multi-argument dispatched methods.  The
term "multiple polymorphism" has similar semantics but is more specific.
Multi-methods are quite general taken literally.  Since CLOS not only
abbreviated the term but TMK were the first to use it for their methods,
some prefer "multi-methods" to apply only to CLOS methods; a rather narrow
view.  Assuming the other contributors in this discussion aren't just being
argumentative, this term may be too confusing to be useful outside of a CLOS
context and I for one will avoid such usage outside of it unless so qualified
(such as "CLOS multi-methods").

For example, Chris wondered if the multi in multi-method stands for multiple
methods per generic function, a truism in CLOS, but has nothing to do with
the origin of the term.

[On packaging vs. friend]

The C++ "friend" notion for classes and functions is finer grained than
packages.  Without friends, related classes and functions have to be
defined in the same package tying barely related classes together.  First,
establish that various classes and methods can access each other in whatever
(directed graph) ways.  All must be declared within a package and with no
required forward referencing all can see each other (which is not desired)
and even with required forward referencing the classes must be linearly
ordered which does not cover all cases and is an unnecessary burden to the
user.  Classical OO classes are like weak classes with packages around them
but since this is reliable IMHO it should be the default.  The rare open
access "friend" case should be considered a carefully watched exception.
Therefore packaging for classing instead of for packaging (its usual purpose
of grouping related objects, classes, types, other packages, declarations,
and etc.) is using the right tool for the wrong job.

>If *your* language has both multi-methods and the O.M(...) notation, how
>do you justify the discrepancy between the notational asymmetry and the
>semantic symmetry?

There is no asymmetry.  The syntax and semantics of a model with receivers
(as is quite common and workable) mirror each other.  And reading symmetry
into the term "multi-methods" is connatative since CLOS simply defines the
term to mean multi-argument dispatch.  No more arguments here.  If you don't
know this, maybe you should before discussing the subject further.

Also, CLOS does not have ordinary functions to my knowledge.  Ordinary
functions treat all arguments equally but I've been told CLOS prioritizes
arguments from left to right during argument matching.  Unless you have
something to the contrary, you'll have to drop the "symmetrical" stuff:
dynamic functions are symmetrical but multi-methods are not (they have a
left-to-right priority).

Anyway, the point I was *trying* to make was that O M ... does not infer
dispatching on only the type of O since typically in any kind of invocation
all actual and formal argument types must match.  You seem to have latched on
to some trivial static efficiency tricks and took them as the general case.
Enough on this, my intention was to avoid confusion by avoiding a lot of
diverse terminology and not to cause even more!

[On Coplien]
Section 9.7 is quite clear on implementing multi-methods in C++ and the method
is completely general.  Enough on this.

[On our languages]
These aren't publically available (nor is detailed discussion).  Version II
should be before too long.  My apologies to anyone waiting on more information.

[On packaging]

Packages are useful for "packaging".  I've used them myself for many,
many years.  I just prefer systems which encourage correct use and
leave most of this burden to the language/compiler.  The "Lisp culture
tends to oppose protection and enforcement, so CLOS does not contain
a real protection mechansim."  I simply disagree with this philosophy;
no need for further debate.  I also apologize for missing CL packages,
I'll add CL to the list of languages with this facility.

>|>Just to check, Bob, do you still think that Smalltalk, C++, and Simula
>|>*have* multimethods? [I don't dispute that you can code up some sort of
>|>equivalent. But you could do *that* in C, or assembler, or Scheme.] If
>|>so, could you explain why?
>|
>|I've already pointed out they don't; to repeat myself: Smalltalk doesn't
>|because its statically typeless and C++ doesn't because it is statically
>|typed.
>
>That's odd, because a few messages back, you claimed that they *did*
>have multi-methods. At least, that's how *I* read what you said; if you
>were actually discussing your company's own language, there was no way I
>could tell, and you certainly didn't disabuse me of the notion.

Nope, you were confused.  You were claiming that O.M(...) meant single
argument dispatch, which was wrong, and which is why you had trouble
understanding my postings.  All of what I said was quite clear with a good
understanding of the issues involved and their context.  But don't worry,
my consulting fee is only $500 an hour and I'll just bill you;-)

[More confusion on static vs. run-time (dynamic) typing and method dispatch.]

Maybe you should consider this issue further before posting any more
specifically on this subject.  It appears to me you're not even close
and I'll often assume someone is when they discuss a subject.  You're Ok
on other points but seem to be still learning on this one.

>|I've designed and implemented more powerful facilities than
>|these myself, please take my word for it when it comes to static and
>|dynamic typing of any kind!
>
>I'd rather you explained your reasoning here, rather than taking your
>word for it.

Just keep them checks com'in, and I'm not cheap!

>If your product is a C++ superset, it's presumably more complex than
>C++, which to me sounds like a severe disadvantage. I don't suppose
>there's a description you can post, or that we can FTP?

Nope, [bragging on] but its REAL good [bragging off].  I'll post when it
becomes available.  Anyway, its done in such a way that your above point
is truly minimized; I've heard it before and enough on that.

>But do we *really* think in terms of ``messages'' being sent between
>objects? [Here, ``we'' is intended to encompass even those poor
>individuals that have never had the benefit of being exposed to
>object-oriented programming.] I think not. In fact, I think that to do
>so is *not* natural for us -- except in those circumstances where those
>messages are constructed by us, for us, from us, and to us.

I already presented a decentralized distributed event-driven model several
times, and you seemed to be surprised at a concurrent model when dealing with
many objects in the real world?  Chris, I'm an old operating systems person and
have done plenty of concurrent programming since then.  Get real or send email
and I'll send some excellent references on concurrent *object-oriented*
systems.  I've even pieced together how NT works (without time-sharing) and
can now even engage in discussions on PC OSs!  [Ekkk.]

[On all OO books (hundreds of them) oriented towards more accurately modeling
the real world.  Chris doesn't beleive me?]

There're too many to list.  Just go to your local technical bookstore and dig
thru a few hundred.  If you do this and don't find literally hundreds of them
(maybe your bookstores stock differently than ours) send email and I'll send
you a list.  I'm not just going to send you the oggles of them lying around
on my (and others) desks.

>Also, note that earlier in this thread Bob seemed to have the view that
>the ``objects'' were given, and things like traffic jams and waves were
>not part of the (objects of the) real world. I'd like details that make
>this distinction stand up.

Wait for the book, Bob Hathaway's "The Next Generation of Intelligent
Real-World Object-Oriented Systems (Don't bother reading anything else).",
1993.  I already covered the above issue but on this enough is *enough*.

>|...
>The Tower of Babel problem arises only when there is no mutual
>comprehension, not just because of the use of a variety of different
>languages.

Good point.

>|                                       In this terminology, the real-world
>|model is like VR, plain and simply modeling and simulating the real world
>|in much the same way that we see it around us.
>
>Would it be correct to describe it as an approximation that uses terms
>familiar to us from everyday life, and thus vulnerable to error from
>both sources?

Not in my view.  It should model the world closely enough to work well at
all levels.  A recursive (aggregate) breakdown or scale up is required if a
level is no longer accurate; like changing representations because some object
was zoomed in or out on - a classical solution to a classical problem.

>|Mental worlds are like semantic networks: they can think, reason, and
>|are conscious.
>
>Mental worlds can think? Semantic networks can think?

Obviously if done well, this is artificial intelligence.  A rose is a rose,
sometimes a cigar is just a cigar, and intelligence is intelligence.
  [With a current bias towards human intelligence.]

>|We are mental worlds.
>
>Well, it's terminology. ``Mental agents'' would surely be better.

Perhaps, but I meant there is a mental world running in your head.
"Cognitive" might be preferred to "mental".

>|Mental worlds are abstractions too but are extremely complex.
>
>So conscious, thinking entities are abstractions? [I happen to think
>that this is true, but I'm not sure that it's really what Bob means.]

Metonymy.  I meant they consist of and deal with abstract representations of
the real world (contain a RWM, so to speak).  IMHO this is a necessary
(but not sufficient) condition for a reasonable definition of intelligence.
And I don't think MWs are "that" complex; I was speaking quickly.

>Is there no room for complex abstractions that don't think and are not
>conscious?

Yes.  Their solution is the goal of software engineering and even the
object-oriented approach.

And thank you for the feedback on the terminology.

[On theoretical physics]

I was trying to point out the more that is known about the universe the
better our models should become.  If you prefer object-oriented models
of some kind (as should be the case of the readership in comp.object) these
OO models will get better (as will any other).

>Encapsulation has little to do with classes -- they are separable.

This is one view.  Please keep in mind that even though Simula and Smalltalk
have several obvious deficiencies due to their seminal work they did set
the stage for the classical object-oriented languages in which classes
enforce encapsulation.  Types enforce a nice kind of abstraction too.

>[That's *theory*, not *theorem*] Well, although a UFT would give better
>understanding at a pretty detailed level, I'd expect it to make
>practically *no* difference to any simulation to do with most ``real''
>objects -- like cars, bank-accounts, weather systems, or molecules.
>Sub-atomic particles and atoms, maybe.

There's a lot of very important simulation to be done in the extremely
small and the extremely large.  Your bias is showing ("real" objects?-)

>But if you can't refine the model to do at least as well as existing
>non-OO theories, what right have you to say that OO is ``appropriate''
>for describing the real world, except as a motivating metaphor? How
>would results from the SCSC *help*?

I can extend it to do better than non-OO approaches.  This was considered
obvious from the simple basis I provided.  Buy my book if you want to see
how *I* would fill in all those details since they were obviously left to the
reader.  I was simply discussing a general object-oriented model and showed
it can apply and I believe can be used to model objective reality.  This
means an OOA can map closely to reality and an OOD can map closely to an
OOA and so on.  I try to keep an open ear to alternatives but with the possible
exception of specialized languages, the current alternatives look much worse
to me from both a conceptual and software engineering point of view.  No
arguments please, for now this is just an opinion.

bob
objsys@netcom.com