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

Internet Message Format | 1992-08-21 | 30.4 KB

From: [e-mail] (Chris Dollin)
Date: Fri, 21 Aug 1992 14:06:58 GMT
Subject: O.M(...) vs M(...), and is the Real World O-O?
Message-ID: <[e-mail]>
Organization: Hewlett-Packard Laboratories, Bristol, UK.
Path: sparky!uunet!paladin.american.edu!darwin.sura.net!mips!sdd.hp.com!hpscdc!hplextra!otter.hpl.hp.com!hpltoad!cdollin!kers
Newsgroups: comp.object
References: <[e-mail]> <[e-mail]> <1#[e-mail]>
Sender: [e-mail] (Usenet News Administrator)
Lines: 634
In-Reply-To: Bob Hathaway's message of Fri, 21 Aug 92 02:18:25 GMT
Nntp-Posting-Host: cdollin.hpl.hp.com


I changed the Subject, because we don't seem to be discussing
conformance and inheritance at the moment. Sorry to anyone who thought
they'd killed the discussion.

This looks like another long one (~~ 600 lines. Should I reduce the
context to save space?). (I've had two votes in favour of continuing
here, none against. Statistics? Sampling? Who she?)

In order to organise my thoughts, I've re-arranged the order of Bob's
response. I hope I have not introduced additional confusion; as before,
I've retained some context. As a happy consequence of this being
a two-person debate, and Bob quoting with ">" while I quote with "|",
you should be able to tell one of us from another (as if the content
wasn't enough!). As a result of the reorganisation, all the stuff about
the invocation notation comes first, so if you're not interested in the
philosophy, you can stop when it starts obtruding.

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

|>|>In the presence of multi-methods, why should one argument to a message send
|>|>have a special syntactic position?
|>|
|>|Because it is the object performing some action, as is always the case in
|>|the real world.
|>
|>Not with multi-methods, it isn't; that's the point.
|
|Uh huh.  You're confusing lack of encapsulation with multiple-polymorphism
|which as I've already stated is obvious and *should* always be present.
|Thats my axiom.

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

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

|This means the status of the receiver is not considered important in
|definition.

Yes, because there is no receiver (in CLOS multi-methods).

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

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

It's just a different way of carving the computational cake. As it
happens, it allows the more conventional style of expression, should you
wish to use it.

|Please keep in mind we used to allow both forms and rejected the idea because
|of poor protection.

[Which ``both forms'' were these? Which ``we'' was this? Which
``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 think it has no bearing on the original topic -- O.M(...) vs M(...) --
so I propose we don't follow it up here.]

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?

|>|Notice that makes the receiver special (which it should be anyway)
|>
|>But Bob, that's exactly the point that's being argued -- should there *be* a
|>receiver, specially marked? Not whether or not you *can* use that notation,
|>and have ``receivers'' as a concept, but whether that's a *necessary* part of
|>OO. If you take ``the receiver should be special'' as an axiom, of course its
|>going to appear as a theorem. But PG (I think) and myself are saying that *we
|>dispute your axiom* -- a distinguished receiver is not *necessary* and is not
|>*sufficient* for object-oriented dispatch.
|
|Please elaborate on "not sufficient".  And I think I've shown it is an
|excellent model that always works.  Can you show another approach is better?

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.

The language could even permit the special syntax, and check that it's
only used on appropriate messages. [I'd hate to be a maintainer in such
a system.] [My preference is to allow ``x.f'' as just another notation
for ``f(x)'', so I couldn't use that syntax anyway. I have used
``o<-m(e)'' as special syntax for monomethods, meaning ``m(e,o)''.]

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

The fact that these things are different to ``objects'' and ``messages''
suggest that Os and Ms are not the only things we might want in
descriptions (of the world, or of computation). Perhaps it's because
they're not the only things in the world, either.

|>|Also, if I write an imperative algorithm without an explicit doer, such as:
|>|  take this
|>|  do that with it
|>|  put this here
|>|  do that
|>|  you're done
|>|
|>|There is the implicit imperative you for each instruction.  If I now reuse
|>|this component by following it myself, handing it to a robot to perform, or
|>|whatever then self becomes the implicit receiver.  In OO any such imperatives
|>|are considered with an implicit self making this algorithm *completely
|>|reusable*.
|>
|>It doesn't need OO to make this reusable; all it takes is an implicit
|>parameter, or an explicit one if you like.
|
|OO has the implicit parameter as above but I'm not aware of any other
|notation which does.

Are you saying that, because no notation you know of has this feature,
that it's therefore an intrinsic part of object-orientation?

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) is held in
the permanent (global) variable ``doer''.

When another doer has to do something, I can call ``please_do'', which
takes a (potential) doer and an action (or a description of same).
Here's please_do:

    define please_do( dlocal doer, action ); lvars action;
        action()
    enddefine;

This temporarily sets ``doer'' to the argument, runs the action, and
then resets ``doer''. There need be nothing particularly OO about the
code.

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

In fact, this brings up a pertinent point. This discussion (about
objects and the real world) started with my endpiece remark ``The real
World is not Object Oriented''. Perhaps I haven't made my position on
this clear. What I mean is that

    the world is not structured into ``objects'' and ``messages'' in the same
    way that (certain kinds of) objected-oriented languages structure their
    data and actions.

I'll not deny that the informal term ``object'' is useful in discussing
the world we (locally) inhabit, nor that it is a motivator for the use
of the same word in OOP. Nor will I deny that there is cross-talk, even
fruitful cross-talk, between OOP and the way in which we view the world.

What I *do* deny is that the ``natural'' way we see the world and our
programs means that the underlying structure of the world is necessarily
``like that'', and that object models are more than an analogy for the
world -- and that they are *worse*, for the purposes of understanding
the world, than other models that we *do* have.

In particular, even when there *are* objects and actions we can agree
on, the description of a system need not attribute the ``doing'' of
those actions to any one object. Making the attribution is a *choice*,
and one can make different choices for different circumstances, with the
underlying system behaviour remaining the same. The fact that we can do
this suggests -- very strongly -- that the actions do not ``naturally''
belong to particular objects, despite our propensity for seeing
``doers'' in the world. Being a doer is an abstract notion, one that we
have invented; it makes sense for us, as part of a community of people,
to ascribe intention and autonomy to other people, and (by extension) to
animals, and (by extension) to the sun, wind, clouds, and rain.

But I deny that clouds are ``doers'' in the same sense that people are.
I even deny that a cloud is an ``object'' in the same sense that a rock
is. If objects are ``in the world'', surely we could give an account of
objects that was satisfactory for all of them -- that said why a rock
was an object and the wind isn't, why teapots are objects but spoonsful
of tea aren't, why bank accounts are objects but space-time isn't?

``Being an object'' is a property given by a *description* of the world.
Bob says (following my quote):

|>If objects are ``real'' -- if being an object is a property of the *world*,
|>not of a *description* of the world -- then we'd all carve the world into the
|>same set of objects, right? But I don't think we do.
|I do.  We all can recognize and distinguish between pencils and people
|since they have discernable properties and attributes.

Well, yes. Certainly this is a common distinction. But I did not mean to
be taken as saying that we *never* share descriptions -- otherwise
communication would be impossible. [Perhaps that's the problem here!]

To take a trivial example, you (Bob) think that a ``push'' isn't an
object. Well, I'll reserve judgement. In previous posts, I have asked
whether several things are objects are not. Bob usually replies by
saying that they are, or are not. I do not agree with all of his
distinctions. Bob seems to think that some objects are ``real'', others
are ``abstract'', and yet others are ``mental'' (have I got that
right?). His distribution of objects into these categories does not
match mine.

Of course, for common, everyday things we're likely to share the notion
-- they'd not be common and everyday otherwise. To test, you have to
push.

[I wrote before]

|>I'm sorry. It is this point on which we seem to have a fundamental
|>disagreement -- or perhaps a terminology problem. This model of the world --
|>that there are objects, and properties, etc -- is a nice friendly (but not
|>universal) one. But you are giving primacy to matter clumped in ways
|>appropriate to the senses which we possess, and the real world is much, much
|>richer than your model allows.
|
|The abstraction level can always be broken down (even dynamically) further
|thru aggregation if the level is too high.  This always works even for your
|shattered cup example.

Hmm, I think I see where this is going.

You identify particles and clumps thereof as ``objects'', and forces
(fields) acting on them as ``messages''. Since particles and forces are
all we know about (I speak loosely; if necessary we can speak more
tightly), and we have this handy renaming, you can now say that the
real-world is object-oriented.

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.

This is just playing word games [some people call this ``just
semantics''. I've never understood why; surely arguing about meaning is
exactly what's important. It's arguing about *definitions* that can be
pointless.]

|>What is the OO interface of my cup?
|
|A spatial representation and the mass properties of the surface and object.
|And maybe any forces it may be giving off.  If I want more detail, I could
|get into molecular bonds as in molecular modeling.  Quite common, I believe.

But these are not the properties we ``naturally'' think of as belonging
to a cup; they are properties that we have come to use to describe the
cup and its internal structure. If I am write an adventure game (let's
amke it textual; I don't wish to worry about vision, etc, here), almost
surely I shall give to the cup some more abstract properties; weight,
bulk, can-be-held, can-hold, and so on. Several of these ``properties''
are abstract notions that we use to describe things in the world.

|What is your prefered interface anyway?

Whichever one works for the job I'm trying to do. Since I don't hold
that natural objects have ``given'' interfaces, I'm free to pick
whichever one suits my fancy. Of *course* I'll try and pick one that
fits the way other people think about the situation, if I have a choice;
of *course* the choice is not completely arbitrary.

|>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
cup can fall apart in an enormous number of different ways. Were all
these parts there before? No. The *stuff* was there before, but the
parts were not.

|>I think it's easier to say here that the ``cup'' is an *abstraction*, a
|>*model* of some part of the real world which behaves in a particular way. When
|>I drop the cup, and it shatters, the abstract notion becomes inapplicable. The
|>``object-ness'' of the cup is an illusion -- it resides in our models, not in
|>the world.

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

|>How do you identify the objects? The interactions? Even the notion of
|>``process'' is part of our *description* of the world.
|
|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.

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

[stuff about "doers" omitted, leading to]
|[Slight admission]
|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.

|> |> So you identify doers with intelligent (or do I mean sapient?) agents?
|> |> But that makes a nonsense of your stack example -- I can talk to the
|> |> dish-stack as much as I like, but nothing happens until I put the tray
|> |> on the stack. Then it ``pushes'' down. You may choose to say that's an
|> |> action performed by the stack, but it seems to me that you'd say that
|> |> just to keep the OO model going.

|Actually, its physical dynamics working on aggregate objects.

Is this an admission that the ``stack'' doesn't know how to push?

|>And a single example is hardly enough to justify such a sweeping statement.
|>What message is sent to the clouds to tell them to rain?
|The event driven approach (as I discussed towards the end of my last
|article) can handle this as a message.  Actually clouds are made up of
|little drops of water, again breaking an object into a finer level of
|aggregate parts seems to work well.

Calling a cloud an ``object'' just means that there's a certain
relationship betwixt the composing droplets that makes it descriptively
useful to treat the cloud as a whole. Recognising the cloud as an object
is a *human act* -- an *invention*.

|>What message to the clock, to tell it another second has passed?
|The little spring component or maybe the frequency of the crystal.
|It seems to me there is always some form of contact, whether physical
|or not and this contact can be modelled with OO methods.  I'm still
|waiting for better way.

What message to the crystal, to tell it that another second has passed?

|>What message to the river, to say ``flow downward!''?
|Gravity, as given off by the earth object.

As I've said above, if you're prepared to call any force a message, then
OK, but I don't think this is a constructive way to use the terminology.

|>What message to the iron, to say ``To the magnet!''?
|The magnetic waves come in contact with the object, the universe does the
|rest.  This one isn't up to the object, whatever it decides.

*None* of these things is ``up to the object'', if we're talking
physics; there's no choice for it (unless you want to go all mystical
about the uncertainty principle). The fact that you have to attribute
the doing to a new abstract object -- the universe as a whole --
suggests that the metaphor is being stretched rather hard.

|Whats the alternative?  Discussions of alternatives would be constructive,
|not just pointing out percieved 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.

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

|>``Bob, break the cup!''. You -- Bob -- are the doer. The cup is done-to. (One
|>of you is the object -- ha! -- and the other the subject of the sentence ``Bob
|>breaks the cup'', but I can't recall which is which and the dictionary entry
|>is sufficiently obscure that I can't tell from that, either. Bah.)
|
|No.  The subject is the implied you.  In "Bob, break the cup", Bob is an
|independent element (as I previously pointed out), the implied subject is
|you (a pronoun standing in for Bob), break is the action transitive verb
|and the cup is its complement (or object).  The fact that the doer (Bob)
|is pointed out first is clear.  There's also: "break the cup, Bob" and even
|"break, Bob, the cup".
|
|As for "Bob breaks the cup" this is not an imperative, it is a declarative
|statement.

Yes, I knew that. My phrasing was intented to avoid confusion about
objects and subjects -- that's why I used the terms ``doer'' and
``done-to'' -- and to make the point that, in English, the doer (the
implied you of an imperative) is usually distinct from the thing that
gets done to; although the *message* of the imperative statement is
intended for the doer. (The doer isn't a receiver, even then, because
the message is usually broadcast, and other potential actors ignore it
-- which is different from not receiving it.)

|Want to go prolog programming today?  It describes an action
|and isn't really good for algorithms; I think, but story telling maybe;-)
|Experience actually.

I'm not sure what you mean by this; we can go and insult Prolog
elsewhere, if that's what you want to do.

|>Better [point of view] for what? Look, my argument is primarily that *there is
|>no best view* -- that you pick a descriptive technique that fits the problem
|>and solution domains. The OO view is good for a class of systems, and I have
|>no objection to *using* it *for that class*. I am not *advocating* a
|>functional viewpoint, but I am advocating that it have equal status with other
|>viewpoints -- that there's nothing *inherently* wrong with it.
|
|For abstract problem solving maybe.  But since I believe in an objective
|reality trying to better understand, model, and simulate it is worthwhile.

Yes, but this has little to do with OO.

|> Bank accounts aren't ``natural objects'', they're invented ones like
|> theatre bookings and your employment contract.
|
|Sounds like a confusion between the RWM and an AWM or MWM.  Cups do exist,
|organizations usually exist as abstractions or subjective views.

Why do you see me as generating a confusion when I've just drawn a
distinction?

|>The point here is that speakers (I generalise from an excellent example :-)
|>*already* treat actions as real, as objects; it is *natural* for them. I know
|
|This is the MWM where actions are obviously objects.  Again, we could just
|be having a domain mixup problem here; I try to deal with all of them at once.

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?

|>I'm pushing the cup in my example. Suppose I have a metal cup and an
|>interesting arrangement of electromagnets, such that when the current flows
|>the cup is thrown several feet in the air. What pushes the cup? The magnets?
|
|Their magnetic fields do since they come in contace with the object.

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

|>Well, that's one view -- seems like magic to me, though. The magnetic field?
|This is subjective; MW here.

I find it difficult to reconcile your use of ``subjective'' here with
your previous comment about ``their magnetic fields do''.

[Bob elaborates his world-view]

|There is a universe.  Space is like a container and time exists
|in it as well, they are components of the universe.

Nicely metaphorical.

| Time and mass are relative to the speed travelled within this universe.
| Space is believed to be curved, probably positively.  This means there
| may be Einstien-Rosen bridges (worm-holes) in it.

General relativity, fine.

| For any good Star Trek model this must be simulated.

Why? The Star Trek universe seems to be rather unlike ours. If you want
worm-holes in the model, just put worm-holes in; you don't need to
simulate them. Unless you're going to simulate the universe from the
bottom up, in which case I advise investing heavily in Cray. And HP, of
course.

| And of course there are the theories for multiple universes. If you
| didn't model the universe as an object (or pass it as a parameter, ekkk)
| minus ten points because there may be many of them.

Passing things as parameters is a very powerful technique; don't ekkk on
it when *I'm* around.

| In fact, the laws may even change from one part of the universe to the
| other meaning the universe had better keep track.

Physicists don't like the laws to change from place to place. When that
happens, they add another layer of abstraction, or introduce a new
field, so that the laws stay invariant.

| You'd better link these universes together, too.  Universes seem like an
| implicit self to me with its assorted laws and contained matter/energy
| existing in (or even creating) space. Maybe I'm not object-oriented
| enough, since matter may create the space around it and may actually
| enforce the laws itself.  Anyway, this explains your gravity and force
| field type of questions.

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.

|>The remark about artificial reality is, I think, irrelevant.
|It is the rule for RWMing; I don't see your point.

I don't understand this, but I seem to have lost too much context. Can
you explain this ``rule for RWMing''?

|>The notion of push is an abstraction, like the notion of cup. The actual push
|>is real, as is the actual cup.
|
|No the push doesn't exist in its own right, as does the cup.  The push can
|be understood in terms of the interactions between the objects involved.
|You're back to confusing a RWM with an MWM.

And the objects can be understood in terms of the interactions involved.
Do the interactions exist ``in their own right''?

|>Yes, and there are no ``objects'' knowing what to do in this description; just
|>plain objects and relationships.
|
|The objects know their physical properties if you take away any abstractions.

You know very well I'll dispute this, because I don't think ``objects
know'' anything, and I think the notion of object is a human invention.

|>In my model the messages carry out the operations; the computer is
|>transparent. [Actually, since I haven't presented a model, you can't say it
|>isn't so, and I can't say it is.]
|
|I meant that given:
|  object msg ...
|        msg ...
|the second form sure looks like the computer (not an object) is executing it.

It looks to *me* like the message (or procedure, or function) (not a
computer) is doing the execution. This is just word-play; you can take
whichever view you like; we both know that at the bottom, the machine is
doing everything. You can abstract this out in several ways -- the whole
point of a HLL being this abstraction, of course -- and which you feel
is natural depends on what you've met before.

|>Well, it's only clearer if that's how the model works, it has sod-all to do
|>with reusability, and it's only closer to reality if the portion of reality
|>you're modelling is modelled that way.
|
|Well, it is how the model works, it is reusable as shown with the implied self
|as receiver (which you have yet to show in a consistent and complete way with
|any other method), and the portions of reality are modelled that way!!!

Yes, *in your instance* -- you haven't made the case for a general rule.
As for a ``consistent and complete way'', none of the examples *either*
of us has presented are complete -- you've done one natural-language
imperative description, and we've both mentioned the O.M(...) notation.

|>Shall I say this clearly? The *approach* I am arguing is *the acceptance of
|>diversity* -- in both the world and our descriptive notations. You are
|>insisting that actions are not real (not objects, and the real world consists
|>of objects). Let me put this clearly: I think you're wrong, that you are
|>excluding other approaches, despite their usefulness; and that this does not
|>strengthen the naturalness of your approach, it weakens it.
|
|I don't think so.  I think you've been skipping between the RW, RWMs, AWs,
|AWMs, and MWs and MWMs all over the place.  I know that actions are objects
|in mental worlds (among others) and I know that that functional approaches
|(or any approach) may due for AWs and AWMs but I find it interesting that
|the object-oriented approaches can still do for all of them and I've just
|been wondering if the reverse is true.

Translation: you have an abstract view in which RW (etc) feature, and in
this view, I have been skipping about between these things. Apparently
this is a Bad Thing. In this abstract view, you can do everything with
objects. Objects are therefore a Good Thing, and the real world is thus
object-oriented.

As a viewpoint, I think ``accepting diversity'' is better, because I
do not believe in ``single solutions'' to large, complicated problems
like modelling the world. Look how many years it's taken to get the
models we have now! Look how many models there are! Physics -- at
severla scales. Chemistry. Biology -- at several scales. Cosmology.
Economics. Medicine. Psychology. Ecology. Calculus, topology, group
theory, chaos theory. Umpteen schools of art and literature. All
different, all having something to say about models of the world, all
with their own vocabulary, techniques, structures, and passions. All
*human* ideas about a world more complicated than we can hope to
understand in detail.

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

Regards,                    | "I always prefered Sherlock Holmes to Dan Dare"
Kers.                       | Nathan Spring, in BBC2's _Star Cops_.