NetNews Usenet Archive 1992 #19/NN_1992_19.iso/spool/comp/object/3321

Text File | 1992-08-25 | 17.0 KB | 362 lines

Newsgroups: comp.object
Path: sparky!uunet!decwrl!csus.edu!netcom.com!objsys
From: Bob Hathaway <[e-mail]>
Subject: Re: O.M(...) vs M(...), and is the Real World O-O?
Message-ID: <[e-mail]>
Date: Tue, 25 Aug 92 22:06:58 GMT
Organization: Object Systems
References: <[e-mail]> <[e-mail]>
Lines: 351

In article <[e-mail]>, [e-mail] (Chris Dollin) writes:
>Sorry, I don't think I am subject to that confusion here. (In fact I
>think the usual way encapsulation is described in OO languages -- with
>all this emphasis on ``keeping the operations in *the* class'' -- is
>another mistake. Hiding names and doing method dispatch are two separate
>things; routinely conflating them is in itself a confusion. In CLOS, the
>equivalent of encapsulation is provided by using the separate namespace
>control mechanism, viz packages. At least that's how I understand it --
>a CLOS person might wish to correct me here.)

I don't.  Firstly, encapsulation does not infer hiding.  There are public,
private and protected functions available.  Secondly, I've previously
discussed that packaging isn't even as powerful as something like C++'s
friend mechanism.

>|>|.......  The languages here obviously have O.M... notation and use
>|>|multi-methods, they always have.
>|>
>|>They *don't* have multi-methods. They *never* have. Bob, is it possible we
>|>have drastically different notions of what ``multi-method'' means? My notion
>|>is taken from CLOS, on which I'm no expert but I think I understand the
>|>basics.
>|
>|I gave you a reference to Coplien (I though you read it already;-) and he
>|defines multi-methods as simply multiple-polymorphism (as we do).
>>
>The term ``multi-methods'' comes from CLOS (I don't know if it was
>inherited from elsewhere, or not) and means that the action performed is
>selected on the basis of the ``message'' and the (types of) all the
>arguments to that message (there is no distinguished ``receiver'' in
>CLOS). I think we agree on this, at least.

Yes, but "multi-methods" now also apply to the O.M ... notation and
O.M ... does not infer using the static types of arguments (see below).
We use this definition and so does Coplien, so I'll present it as a given.
The only real difference, as defined in C++, is the receiver can only
undergo standard conversions (including derived to base casting) and not
user-defined conversions.

>|And I don't like hearing that multi-methods are a superset of OO dispatch.
>
>Not liking it is your problem, because they *are* a superset.
>Conventional OO dispatch is simply the case where a particular argument
>position is selected and the (types of) all other arguments ignored [for
>the purpose of method selection]. This is usually combined with a
>special syntax for method invocation (message sending, whatever).
>Sometimes this is the *only* syntax (and semantics) for invoking
>actions. [Yukk.]

This is wrong.  For the fifth time, all dynamic types of all arguments are
used in our systems here with the O.M ... notation and they always have
and IMHO they always should be in any system where this applies.  Coplien
uses the same terminology, that using the dynamic types of all arguments,
with M ... or O.M ...  notation, is called multi-methods.  Please don't get
this wrong again, its getting ridiculous.  You can say: "We in CLOS don't
like others using the O.M ... notation to use the term "multi-methods" for
their multiple-polymorphism even though this is becoming a standard practice."
But I think a single term is preferred to two.

>|They are much weaker from my point of view because they aren't encapsulated
>|within a class.
>
>This is not an issue of *dispatch*, but an issue of *hiding*. CLOS
>provides two independant mechanisms to do two different jobs. Naturally
>using only one of them will not give you the power of both.

But you haven't shown that M ... is a superset of O.M ... in terms of
dispatch.  And most OO languages provide both notations anyway.

>|Please keep in mind we used to allow both forms and rejected the idea because
>|of poor protection.
>
>[Which ``both forms'' were these?

Allowing methods to be declared inside or outside of a class.

>Which ``we'' was this? Which

At this company.  We have a first and second generation OO language.

>``idea''?] The protection offered by OO languages is twofold -- name
>hiding, and automated method selection. CLOS has both. [What it
>*doesn't* have is static typing. This is another independant issue, and

  [I thought CLOS specializers provide for static typing with parameters.]

>I think it has no bearing on the original topic -- O.M(...) vs M(...) --
>so I propose we don't follow it up here.]

With class encapsulation the correct use of an object can be guaranteed
and the integrity of objects insured but without it (CLOS programs)
this isn't true because a function can be declared anywhere and have
complete access to all of a class' representation, at least if this
new package construct (which I haven't ever seen used or defined for
CLOS) is forgotten in even one place.

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

>It ``always works'' because it's embedded in a programming language in
>which you can code up the alternative (multi-method) dispatch yourself.
>It's ``not sufficient'' because when you want multi-methods, they're not
>there, and you have to write the machinery out (several times).
>Multi-methods are better, because receiver-oriented dispatch is just a
>special case.

This is wrong since we have had true multi-methods (or multiple-polymorphism)
with the O.M ... for some time (in the languages used and developed at this
company).

>|OO still supports operators (including overloading), just look at C++. This
>|is an AWM, however.
>
>Yes, C++ supports compile-time overloading (and run-time OO dispatch) --
>losing out on the unification. Sad.

I won't comment on your terminology but I think you'll be interested in my
C++ superset when it comes out (should be sometime next year).  It beats
CLOS and Self (but runs infinitely faster) and obviously beats C++ (but
is infinitely more powerful).  Put that in your cereal bowl with strawberries!

>...
>Suppose I write a set of Pop procedures which perform actions. The
>``doer'' of the action (let's say they are known to be the doer because
>their energy level gets drained, their experience level goes up,
>observers are informed that the doer has done something, etc)

  This sounds like a world model.

>is held in the permanent (global) variable ``doer''.

  This is not, this is just terrible.  There may be many doers.
  When going AI, stay AI...

>...

More contrivances.  Yes, other schemes can work but the scheme I presented
is natural, complete, and works well.  Anything could be used but the
instructional 2nd person is excellent for algorithms and has its place
(as it always has.  Maybe you're the person who never reads the
instructions:-)


-- Philosophy mode now ON ---------------------------------------------

  Chris goes on to say that the world isn't made up of objects and
  interactions aren't objectively broken down into objects and their
  associated actions.

I believe the world is made up of objects and their behavior is meaningful.
OO can be used to describe the world even at the most elementary level - an
atom class, a proton class, an energy class, ... - and OO provides a good
way of modeling it.  I believe Chris falls into a vocal minority because
of the ubiquitous and voluminous amount of literature and opinion against
him.  A few academic arguments seem to make their way against OO but I
don't see them gaining popular acceptance in the software engineering
community.  Chris then makes a good point, the same one that Grace Hopper
used to make, that perhaps there should several languages with one for each
branch of science and that special purpose machines should be built for them
such as the IBM machines which were built to handle the kinds of numbers
usually found in the data processing industry.  I used to disagree with this
philosophy because of a feared Tower of Babel problem and because I assumed
the descriptive power of something such as OO would or could be made
sufficient for any domain, and perhaps it is.  I am reconsidering this point;
however, since I've now seen and heard it in many places and from many
people.

Perhaps the phrase:

  The World is Object-Oriented.

is better served by:

  The world can be described as Object-Oriented.

Chris and a few others may disagree but the consensus in the literature
clearly shows the above to be the majority view and theirs to be a minority.

>...
>If that's all you mean, I can't really quarrel with it. But if I call
>forces ``functions'' and particles ``values'', I can claim that the real
>word is function-oriented.

But particles can change state in the real world, the functional model
doesn't capture this naturally/objectively.

>|>If you take this view, suppose that the cup shatters into a
>|>lay-persons-million pieces. Where's the cup? From whence came the pieces?
>|Broken into its constituent parts.  The pieces came from its mass.
>
>But a cup doesn't *have* ``constituent parts'' (unless you count the --
>human, abstract -- separation into ``handle'' and ``container''). The

Yes it does.  The molecules and so on making up its mass are its aggregate
parts.  They were there to begin with and they still exist now but in a
different form.  This is the most natural case of aggregation I can think
of.

>|Depends on your domain of discourse: RWM, MWM, or AWM.  The latter two
>|usually don't worry much about dynamics and space much.  But the former
>|does.
>
>You'll have to explain these terms in more detail, I'm afraid.

First, these terms were made up by me for my own purposes because I am not
aware of any other such delineations.  I asked for comments on them some
time ago but didn't get any responses.  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.  Mental worlds are like
semantic networks: they can think, reason, and are conscious.  We are mental
worlds.  Abstract worlds are abstractions.  Mental worlds are abstractions
too but are extremely complex.  I find the distinctions useful since simple
programming is typically used for abstract world modeling and something
more elaborate is appropriate for RWMs and MWMs.  All of these can be
described by object-oriented techniques but in different ways.  I think all
of your examples fit cleanly into these models.

>|But I still believe in an objective reality.  We may have trouble seeing it
>|but its there none the less.  Maybe I should take up theoretical physics
>|again.  Maybe even solve the unified field theorem; then I'd have a strong
>|argument now wouldn't I;-)
>
>I believe in an objective reality, too, and that it's hard to see. Where
>we disagree is that I don't think that the notion of object-oriented
>that appears in OOPLs is particularly appropriate.

Yes, we disagree here.  I believe OO can be used to describe the real world
in terms close to an objective reality.  For instance, if I invented a
language based on the real-world I could start with an OO description
and simply enforce everything in the language instead of thru classes.
There would still be objects but not much would change.

>Finding a unified field theory (hard; you don't just stub your toes on them,
>or have a feeling about them in your gut) would surely be a triumphant
>*denial* of the ``objectness'' of the real world).

More disagreement from me.  I still think you're in the vocal minority;
maybe we should have a comp.object poll?  Send email if you'd like to
follow thru on this; the results should prove most interesting.

>|Ok, I've wondered about alternatives to the behavioral interface myself.
>|I may have jumped the gun here but I don't see better alternatives.  I
>|still question the lack of encapsulation, maybe its just a bias, maybe not.
>
>The lack of encapsulation in what? -- I've lost track. There is precious
>little encapsulation in the real world (light cones and black holes come
>to mind as examples), and I've already stated my view (above, and
>earlier messages) that [a] in CLOS, encapsulation is provided by
>name-hiding, and [b] encapsulation is a property we choose to give to a
>language in order to make aspects of it easier to handle.

Encapsulation is a property we give to classes to insure abstraction.
Encapsulating a "weak" (CLOS) class and it methods within a package is
the same as "strong" (classical OO) classes but I've shown in previous
postings the former is even weaker than C++'s classes and friends!

>|Actually, its physical dynamics working on aggregate objects.
>
>Is this an admission that the ``stack'' doesn't know how to push?

Yes in the RWM domain.  A stack that can push in the AWM domain
is useful because it is a behavioral abstraction.

>|Whats the alternative?  Discussions of alternatives would be constructive,
>|not just pointing out perceived differences with reality or even our ability
>|to determine a models closeness with it.
>
>The language of physics *is* an alternative -- when you want to talk
>physics.

Good point.  But abandoning a general-purpose tool in favor of many
special purpose ones requires strong justification.

>|>So, at the very least, your objects are autonomous processes -- unlike the
>|>object models supported by Smalltalk, C++, and CLOS?
>|These are weak models.  Try Ada.
>
>A better example would be CSP, if we want to talk processes. It's not
>clear to me now what your notion of (programmatic) notion of object is
>-- I had assumed it was something like a Smalltalk object, but now it
>appears to be an Ada process. OK, we can give some sort of interface
>specification to a process.

Or Argus or distributed Smalltalk or Dragoon.  But I wouldn't use
the term "process" here.  The term "Active Object" is preferred by me.
All the Actor models apply too.

>Earlier, you argued that ``naturalness'' was a key attribute in deciding
>how the world was structured. Now you say that some things, while
>``natural'' (treating a push as an object) are in a different domain to
>the others. How does one tell which is which?

If its in your head its in a MW.  Your head is in the RW (hopefully:-).
The programs you're writing are probably dealing with an AW, seen and
designed by a MW and exist in some representation in the RW.  If your
programs deal with MW's they are MWMs.  If they deal with reality as we
see it they are RWMs.  If they deal with abstractions they are AWMs.  I
find these distinctions useful and wouldn't mind hearing about perceived
flaws.  They are just personal contrivances for my hobbies.

[By my terminology, your not so real mathematical real-world simulations
fall into the AWM but approach a RWM.  Perhaps they lie somewhere in between.]

>``Contact''? What does ``contact'' mean for a magnetic field? I was
>rather under the impression they extended to infinity (unless confined).

Any object occupying space affected by a magnetic field.  Obviously
proximity effects the strength.  A unified field theorum is necessary
for better understanding, modeling and simulation.

>Well, it's wonderfully metaphorical, but I don't think it *explains*
>anything -- I expect an explanation to have more detail, more power, to
>allow me to make predictions, when it's being presented as a Grand World
>Model.

Well, I'll just consult with Einstien on this one (that should be
interesting).  I meant to show the object-oriented techniques can be
used to describe reality and not to present a complete model.  [It should
be easier if the new super-collider gets continued funding and gets finished
on schedule in 1999 but I'm not going to claim to be an expert on this
subject; as a software engineer going spacebuilding I would consult with
one.]

>|>|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.
>|>
>|>It's not that it's *subjective*, it's that it's *abstract*. (Subjective would
>|>suggest that it's private to the individual.)
>|
>|You're confusing AWs with MWs (to which I was referring).
>
>That's what your model says. Do you have references?

Nope, my terminology is completely contrived because I'm not aware of any
other distinguishing between these domains.  Relevant references are welcome.
To reiterate, I was (perhaps unclearly) referring to a mental (or cognitive)
model in ones head and not some programmatical abstraction; you drew the
distinction but mistook the former for the latter.

Regards,
bob
[e-mail]