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

Internet Message Format | 1992-08-26 | 35.2 KB

Path: sparky!uunet!zaphod.mps.ohio-state.edu!uakari.primate.wisc.edu!sdd.hp.com!hpscdc!hplextra!otter.hpl.hp.com!hpltoad!cdollin!kers
From: [e-mail] (Chris Dollin)
Newsgroups: comp.object
Subject: Re: O.M(...) vs M(...), and is the Real World O-O?
Message-ID: <[e-mail]>
Date: 26 Aug 92 17:11:37 GMT
References: <[e-mail]> <[e-mail]> <[e-mail]>
Sender: [e-mail] (Usenet News Administrator)
Organization: Hewlett-Packard Laboratories, Bristol, UK.
Lines: 763
In-Reply-To: Bob Hathaway's message of Tue, 25 Aug 92 22:06:58 GMT
Nntp-Posting-Host: cdollin.hpl.hp.com


The usual quoting conventions apply. Over 700 lines this time, but
there's lots of context -- just as well, since we've had a gap of
several days.

In article ... Bob Hathaway <[e-mail]> writes:

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

[I have no referent for the ``I don't''.][That's ``imply'', not
``infer''.]

First, I claim that encapsulation and name hiding are both mechanisms
for accomplishing the same goals -- namely preventing unauthorised
access to certain functionality. OO encapsulation does so by hiding
certain names according to the class structure. I think name hiding
should be *separate* from class (or type) structure.

Second, the public/private/protected distinction is not common to even
all the languages notmally thought of as OOP -- it is lacking in
Smalltalk and Simula, to name but two. It's not clear to me what your
linguistic base is -- do you argue that the tripartite distinction is
*essential* for OO?

Third, if the name-control features of ``friend'' were thought to be
sufficiently important outside their originating C++ context, I'm sure
corresponding concepts could be generated for name-hiding and module
structures. I seem to have missed your discussion on the inadequacy of
``packaging'' to do what ``friend'' does; perhaps you could summarise.

Fourth, I argue simply that tying name-hiding to class structure is
simply unnecessary and confining -- that it is simpler and more powerful
to disconnect them. If this means that modules must have friends (and
I'm not sure I believe they do) then so be it.

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

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?

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

Ie, it's not multi-methods, although you can make it do some of the same
things if you try hard enough.

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

Up until this message (at least in this series) you had not said that
you were discussing a language invented by you-plural. You had claimed,
or appeared to claim, that the use of the types of all arguments (for
dispatch) was a property of other OO languages, particularly those that,
in fact, do not possess it.

Subject to a discussion of you actual rules for dispatch, this looks
like multi-methods, *except* that your remarks above suggest that the
rules are asymmetric, ie, biassed toward the O of the O.M. In this case,
I suggest that you stop referring to them as ``multi-methods'', as this
name is already taken for the symmetric case.

|Coplien uses the same terminology, that using the dynamic types of all
|arguments, with M ... or O.M ...  notation, is called multi-methods.

Using the index in Coplien, I find:

p176: ``In more general terms, what is desired here is the selection of
a member function base on the type of *two* objects participating in an
operation. This facility, not directly available in C++, is called
*multi-methods*. Multi-methods will be brought up briefly again in
Section 9.7.''

p327 is listed in the index, but does not seem to actually have any
material on multi-methods.

pp349-350, in the aforementioned Section 9.7, titled ``Multi-Methods
under the Symbolic Idiom'': Referring to selection based on (the
types of) *two* arguments, Coplien says: ``Using the types of multiple
operands to choose a member funtion or operator at run time is called a
*multi-method* in object-oriented programming languages embedded in
Lisp.''

He then goes on to describe how to implement two-argument multi-method
selection in C++.

|Please don't get this wrong again, its getting ridiculous.

Look, Bob, what I *said* was that conventional method dispatch, as
evinced in Smalltalk or C++, is a special case of multi-method dispatch.
You can't show me wrong by saying ``but my system has multi-methods, so
you're wrong''. What's more, Coplien is showing how to *implement*
multi-method dispatch, *given* mono-methods and a notation which
encourages the asymmetric notation. (In fact, the eventual
implementation -- of a generic ``+'' on a tower of Numbers -- uses an
overloaded *global* ``operator +'', not a member operator, so he
*avoids* the asymmetic notation not only at the call site but at the
point of definition!)

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

``We in CLOS''? Have I not made it clear that, although I know a little
about CLOS, I do not regard myself as a member of the community? I would
not presume to speak for them. I speak for myself, using the syntax and
semantics of CLOS as a basis for counter-examples to some of your
remarks.

Now, *if* the method dispatch is *semantically* symmetric in all its
arguments, then I have no quarrel with using the term ``multi-method''
for it. But, in this case, I cannot see the point in the syntactically
asymmetic notation, since you haven't got a semantically distinguished
argument, and -- as you observed several messages ago -- we'd like the
semantics to be to suggested by the syntax, or -- as I'd put it -- we'd
like to design the syntax to reflect the semantics.

But, *if* the dispatch is not semantically symmetric, then it's
different from what ``multi-methods'' mean in CLOS. I think it's a
matter of respect to the CLOS community not to hi-jack their terms from
them. In any case, the term already *has* a clear -- CLOS-based --
meaning (which is shared by Apple's Dylan and Steve Knight's
``objectclass'' extension to Pop11), so by using the same term you're in
danger of inducing confusion.

A single term is preferred to two when *either* the denotations of the
two terms are the same (which is for you to prove, since only you can
tell us what *your* languages semantics is), *or* when the two uses are
in such widely disparate fields that no confusion will arise -- which,
by example, is clearly not the case here.

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

Assuming that the O.M notation is used for mono-methods (which, from the
point of view of the *language*, is true in both C++ and Smalltalk),
it's surely clear.

Where we have a class C1 with a mono-method M1 on self c1 and arguments
a1i, we can write a multi-method description

    define :method M1( a1i, c1: C1 ); ... enddefine

(A CLOS expert can supply CLOS syntax; this is ObjectClass syntax, I
hope, hence the Popish move of the self argument to the final position.)

Repeat as necessary for the other mono-method definitions. Hence, you
can write mono-methods just as you could in a conventional language.
What's more, you can, if you choose, discriminate on *other* arguments
to the method. It is in this sense that I mean that multi-methods are a
superset of mono-methods; mono-method dispatch is just the case when you
only discriminate on a particular argument position.

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

To the uninitiated (eg, me), ``we'' sounded as though it was supposed to
mean the OO community as a whole. Perhaps you should share your data
with us. For example, were you using a proper module mechanism when you
discovered you had ``poor protection''? If not, it's hardly a surprising
result.

Of course, if you don't really believe in symmetric (multi-method)
selection, then perhaps there are things you think of as ``poor
protection'' that I think of as ``reasonable access'. Which is why I ask
for data. The approach, the problems, the solutions considered --
*these* are at least as valuable as your conclusions. Without them, how
can we know if your solutions apply to us? [``us'' is ``anyone out here
listening'', not -- for example -- just Hewlett-Packared.]

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

No, as I understand it, it's all dynamic -- at least in principle, ie, a
``smart'' compiler might be able to exploit the information at
compile-time, but it's not abliged to.

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

What ``new'' package construct? Packages have been in Common Lisp from
the beginning. To hide a class, stuff it in a package, and export only
the functions that you wish others to use. That's the ``one place'' you
mustn't forget to put it. After that, you cannot access *anything*
[!below] about the class without using the package. Even if you use the
package, you *still* haven't got access to the hidden -- non-exported --
functions. Are you sure you know how Common Lisp packages work?

[!below: well, actually, it's possible to violate this hiding, for
example by using the ``::'' operator -- or its run-time equivalent -- to
get at *any* symbol inside the package. The question is, how much
protection do you want? It's possible to inspect code -- automatically
-- for such dubious uses, and reject them. I am more interested in
preventing *mistakes* due to using features that should be hidden than I
am in preventing malicious attack. After all, in C++ nothing prevents me
from rooting around in the source and doing some slippery casting to get
at private data, if I really want to. If it were needed, Common Lisp
could grow a way of disconnecting the symbols in a package from their
values, once that package was ``completed'', making the attack I
suggested impossible.]

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

You reasoning is a little difficult for me to follow, because it seems
that if both static typing and static non-typing rule out multi-methods,
then *no* language can have them. Fortunately, (the
non-statically-typed) CLOS *does* have them, at the cost of disposing of
the first half of your argument above.

My position here is that static vs non-static (dynamic) typing is an
independant issue -- that is, both statically and dynamically typed
langauges can have (or not have, of course) multi-method dispatch.

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

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

As above, *if* you have multi-methods you can *still* use the O.M(...)
notation, but the grammar no longer reflects the semantics -- which, by
your own standards, is a Bad Thing, no?

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

The fact that you said that you won't comment on my terminology suggest
that you have something you want to say. Spill it.

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?

As for my cereal bowl, I'll have you know that I don't pollute
strawberries with cereal. What goes on cereal is banana yoghurt. Failing
that, blackberry-and-apple ditto.

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

Yes, and then I showed how in Pop I could cope with multiple doers, to
which you said:

|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

All code is contrivance. It might be ``natural'' (which means ``you're
used to it''). It might be ``complete'' (but how would you tell?). It
might ``work well'' (which might mean that you've missed the failures or
twisted them). In fact, I find treating the algorithm as a set of 2nd
person commands is *unnatural*, and likely to be *incomplete* --
showing, once again in this thread, the subjective loading of the term
``natural''.

|(as it always has.  Maybe you're the person who never reads the
|instructions:-)

I'm probably the one who does, and then rants at the manufacturer
because they (the instrcutions) are so bloody awful.

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

*On the human scale*, this is sort-of true. I have not disputed that the
human notion of ``thing'' -- cup, pencil, person, tree, etc -- fits our
way of thinking, and is useful. How could it be otherwise? Would -- or
could -- we continue to think in a way we recognised as useless, or
meaningless?

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.

When we move away from this human scale, the appropriateness of the
notion of ``object'' begins to be disputable -- to which this discussion
bears (a little) witness. Of course the object metaphor can be pushed
further; we humans are creative, after all.

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

OK, then, Bob, 'fess up. Let's see the model, an OO model. First tell us
what *you* mean by an OO model. Then give us models for atoms, protons,
etc. Or, better, give us criteria by which we can recognise objects, so
that *we* can try. [If you have an energy class, does that make
``energy'' an object?]

|I believe Chris falls into a vocal minority because of the ubiquitous
|and voluminous amount of literature and opinion against him.

Well then, let's have the references. Let's say ten works which take the
view that the world is object-oriented in the style that Bob has
described in earlier posts.

I am *not* interested in works by the sellers of OO methods or OO
language designers, unless they specifically address the issue of the
``universality'' of OO. I *am* interested in works by physicists,
philosphers, and psychologists. If you (Bob, or any other reader) don't
like these criteria, let me know why.

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.

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

Heavens, Bob, I'm not saying that OO isn't useful, or that it's not
popular (not that popularity has a great deal to do with truth). I'm
saying that it's not universal, and that we shouldn't mistake a
programming and design technique that works tolerably well for systems
that humans have built for a universal description of the world.

|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 made a point that may bear a family resemblance with Hopper's, that we
should be prepared to use a variety of notations in capturing the
bahaviour of a system. This is *not* the same as ``one language for each
branch of science'', and I don't really think we should go for
special-purpose machines for running different kinds of programming
language -- although it *is* true that I would like more support for
tagged pointers, and expect to need rather different kinds of
programming languages for massive parallelism than, say, C++ with
threads.

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

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.

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

Some *parts of* the world can be described by using OO.

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

What consensus? What literature? What price popularity?

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

What do *you* mean by ``functional model''? If you mean something like a
VDM description, with ``functions'' or perhaps ``procedures'' or
``operations'', we can have something like

    operation xmove
    reads particle.where
    changes particle.where
    result particle.where.x = old particle.where.x + 1

This seems to capture the particles state-change in a perfectly natural
way.

If, on the other hand, you mean ``using pure functions'', then your
notion of naturalness may need retraining (``naturalness is not a
given'')

    def xmove p:particle = particle (x => p.where.x + 1, y => p.where.y)

Of course, tying this update into the rest of the system may be
difficult, but that may be part of the problem rather than part of the
notation. Or it may not. (I regard this as an open issue; remember that
functional programs *can* talk about implicit state, otherwise doing a
denotational semantics for an imperative language would be impossible.
Of course, this boils down to ``how much coding can you stand?''.)

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

So the constituent parts of a cup are its molecules?

(a) then the cup is an abstract object -- it's just a name for the
aggregate *and the relationship between its parts*. Clearly the
relationship is important -- consider a cup made of Plastecine (no, I
can't remember the right spelling) which I can deform into a sphere
(pretty useless as a cup), a ring (ditto), or a cylinder (dditto). [This
does, however, show that polymorphism is a Real World property!]

(b) If I hit the cup *really hard*, I can knock the atoms apart.
(Actually, I can do that to a limited extend by giving it a positive
charge. This is especially easy if it is made of metal.) Now it's the
*atoms* that are abstract objects.

(c) If you go down to the underlying physics, There Are No Objects.
[Physicists please let me know if I'm wrong!] Objects are an
interpretation we place on the physics to make it comprehensible on our
scale and with our intellect.

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

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?

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

Mental worlds can think? Semantic networks can think?

|We are mental worlds.

Well, it's terminology. ``Mental agents'' would surely be better.

|Abstract worlds are abstractions.

Ah.

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

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

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

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

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

OK< we disagree. Mind you, our readers probably already know this.

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

Let me get this straight. You think that a grand unified theory, which
(so far as we can tell from current physics) would have little or
nothing in it that would be describable as an ``object'', would *not*
deny the ``objectness'' of the world? That the absence of objects from
the description would *support* the notion that the Real World is Object
Oriented?

Then you wish to make a descision about the physics of the situation by
a popularity contest among the readers of comp.object -- nay, just those
who have taken the trouble to read the reams that we have jointly been
writing? [Well, at least four people have read at least one of the
posts, not necessarily the same one.]

It might make interesting sociology, but I'm burning enough time on this
already.

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

Which is about the same as my point [b] above.

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

Let's not be so pejorative. What you seem to be saying here is that CLOS
with packages is as good as (from the encapsulation viewpoint) as
``classical'' classes (which I suspect is an understatement, given the
separate flexibilty of packages), but that a system with additional
name-control has more name-control (== more powerful) than a system
without it.

Or, to put it another way, if you think ``friends'' are important, I can
add them to a general, class-independant name-hiding system.
Encapsulation has little to do with classes -- they are separable.

[Of course, you have to demonstrate the the additional ``power'' of
friends actually buys you something in real life.]

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

I'm sorry, I thought part of your argument was that the real world had
objects and messages, and that the objects knew what to do in response
to the messages. Are you now saying that this is *not* the case, and
that the object-oriented description is an *abstraction* of the real
world?

And, if we're confining ourselves to some abstract world of
descriptions, why can't I have my *actions* (commands, messages, generic
functions, whatever) doing things, with the objects being passive?

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

Of course. And the justification is that physics does not contain the
kinds of things we often want to talk about -- such as bank accounts,
prey/predator relationships, windows, gearboxes, and community groups.
Hence the need for a variety of languages.

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

I don't mind -- here, the two terms seem to mean much the same thing.

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

That begs the question.

|Your head is in the RW (hopefully:-).

So does that :-)

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

Well, it's just terminology, right? Incidentally, you seem to suggest
that models and programs are the same (at least, you have given no
examples of non-programmatic models). Is that right? I woyld not like to
so restrict the term.

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

Don't think ``boundary'', think ``centre''.

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

That's most of them.

|Obviously proximity effects the strength.

Of course, but the model has the field going out to infinity.

|A unified field theorum is necessary for better understanding, modeling
|and simulation.

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

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

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

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

Surely this distinction is meat and drink to philosophers? There must be
*loads* of stuff on this. Anyone got references -- there must be at
least *one* reader hot on philosophy.

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

I did? I said it was *abstract*, and I didn't mean that it was
*programmatic*; I meant that it was a mental notion, but one that could
be shared, rather than private to the individual (the latter being
``subjective'', the term being -- I *think* -- the appropriate one to
use. Philosophically speaking.)
--

Regards,    | "If taking devious pains was a sign of laziness, he was quite
Kers.       | prepared to call Hazelton the laziest man alive." Blish (m-o-l)