Newsgroups: comp.object


WARNING. Long (600+ lines). This discussion has turned rather philosophical;
mail me if you think it should be moved to email or to a different newsgroup.
It also won't make all that much sense if you haven't seen the previous
messages, although part of the length of *this* message is due to quoted
material to try and preserve some context. Caveat Lector.

In article <+_#n6_a.objsys@netcom.com> Bob Hathaway <objsys@netcom.com> writes:

|In article [...] kers@hplb.hpl.hp.com (Chris Dollin) writes:
|>That's true, but it works in the other direction; you *pick* a grammar to make
|>the *concepts* clear in the language, rather than picking up some grammar
|>that's been lying around like a dirty sock and trying to fit it onto your
|>hands.
|
|I'm surprised you refer to our programming language's English heritage that
|way; maybe you prefer Lisp:-)  Lets not get into this argument again but
|everyone knows English (excepts maybe the French (ha ha, just kidding))
|and it therefore comes most naturally to us; hence our languages gramatical
|bias towards the imperative invocation.

I am moderately well-known for preferring Pop rather than Lisp :-) (although I
perfer Lisp to English for programming). And the point about English is a
serious one; it is but one of many natural languages, not all of which share
its syntactic quirks (although the underlying *models* of the speakers may be
the same as those of English-speakers).

And using ones natural languages syntactic biases as the basis for modelling
the real world (I note that both of us seem to agree that it exists) seems
shakey -- (a) were constructing *artifical* (programming) worlds, and (b) the
world is not as easily described as English might have you think.

|>That's if you *assume* that the objects exists with the interface (etc). It's
|>not a given, it's a choice.
|
|Not really.  The real world is made up of objects and they do possess
|properties and attributes and etc.

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.

|Current object-oriented techniques simply use a behavioural (or
|observational) approach to defining these object's externally visible
|interface to the world.

They have a particular descriptive style which they use. Models are built
which allow properties observed in the real world to be immitated by the
object-oriented description. The objects, and the interface, are properties of
the *description*, not of the *world*.

What is the OO interface of my cup? Can you enumerate *all* the methods that
can be applied to it -- sorry, that it can execute? Any model you construct
(OO or not) will be an *approximation* to the cup. And that's all one demands
of a model -- that it be a good enough approximation.

If my cup is an object, what happens when I drop it and it breaks? Suppose the
handel [Hallelujah!] comes off. Is the cup now one object? Has it changed
state (lost the ``handle'' attribute, perhaps)? And the handle -- is it now a
separate object, and, if so, did it exist before (maybe the aforementioned
attribute)? 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?

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.

|Analyze any process and you'll find a set of objects interacting with each
|other.  This occurs at all levels in the real world.  I don't see how this is
|questionable, it is an objective fact.  Do you really dispute this?

I translate this as ``I can force-fit my obect model onto anything that
happesn in the world''. When the cup breaks, what are the objects, and how are
they interacting? How formal are you prepared to make this model? If it's just
a handy way of speaking, then you don't need to get formal, but your basis for
claiming any sort of deep reality vanishes. If it's actually a precise
description, then you need to supply a whole lot of detail -- just saying
``you'll find a set of objects interacting with each other'' isn't good
enough.

How do you identify the objects? The interactions? Even the notion of
``process'' is part of our *description* of the world.

|Anyway, there are many ways of viewing this objective reality.  I'll
|admit this may be disputable.

On the contrary, I strongly agree that there are many ways of viewing the
objective reality. But I don't regard the lexical coincidence (objective ~~
object-ive) as particularly compelling argument.

|All object-oriented texts justify a view based on the real world, try Booch
|OO Design or Rumbaugh et al OO Modeling and Design for some examples and for
|a jillian reasons why.

For the purposes of doing an object-oriented design (or indeed any other kind
of design), of course you look to the real world. What point would there be in
modelling a pretend one? And, to do an OO design, what more natural than to
treat the world as OO? If it does the job, that's fine. But that doesn't mean
that the world *is* object-oriented, or that other techniques aren't also
useful.

In Fusion (if I may be permitted a note of advertisment; Fusion is the OO
analysis and design method we have built here at Bristol), we carefully
distinguish to stages: analysis and design. *Analysis* attempts to identify
the objects and their relations, and the operations that can be applied to the
system being modelled. At this stage we do *not* talk about ``methods'' and
``interfaces''; we concentrate on describing the *relationships* that hold
before and after operations have been performed. It is at the *design* stage
that we allocate operations to objects, and make the *choice* as to which
objects have which methods.

After all, there are many designs that can satisfy the same analysis, and they
can present objects with different interfaces. Which one you pick is going to
depend on various factors -- the existance or otherwise of existing
vocabularies, and the target programming language, to name but two.

|>In the software reality, M can certainly be the doer; consider CLOS, for
|>example, with generic functions rather than objects-that-know-how-to.
|>
|>In physical reality, doers are not "sent messages" that tell them how to
|>change their state.
|
|Yes they do.  "Bob, go to the store" is a request for an action.

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.

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? What message to the
clock, to tell it another second has passed? What message to the river, to say
``flow downward!''? What message to the atom of tritium, to say ``decay!''?
What message to the iron, to say ``To the magnet!''?

Now, you can tell me that there are indeed messages for these things. But if
you do, I am likely to say that you have stretched the concept of ``message''
so far that it no longer seems to say very much; if any physical interaction
is a ``message'', then yes, perhaps your objects are real (and sub-atomic),
but we may as well use the terminology of physics, not computer science.

|And doers don't just change state, they can perform actions or even just
|think about things although you might refer to the latter as a state change
|(but I still don't like connectionists (just kidding :-)) and they are
|usually quite capable of inciting their own actions.

So, at the very least, your objects are autonomous processes -- unlike the
object models supported by Smalltalk, C++, and CLOS?

|The imperative of making requests and issuing commands is ubiquitous, so I
|dispute the logic of your above statement.

Well, it's ubiquitous in human society, I'll grant you that. But us humans
form a pretty small part of the real world. Even if we include the entire
biosphere in the request/command world, it's *still* a tiny part of the real
world.

If what you're saying is that the imperative metaphor pervades the kinds of
systems which we wish to model on a computer, and consequently the notions of
``doers'' and ``messages'' are sueful enough to be parts of our language
vocabulary, well, OK; but that's a pretty far stretch from saying that objects
are real, and that THE real world behaves in an OO fashion.

|>Even the normal (English grammar) notions distinguish the
|>doer (which performs the action) from the done-to (which suffers it).
|
|The many examples, such as the imperative request for me to go to the store,
|show this not to make sense so again I'll have to dispute your logic and ask
|for an elaboration.

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

|>That's one way of describing the situation, yes. But it's not a matter of
|>natural law; it's a matter of how you choose to *describe* stacks. Certain
|>things happen, and certain relationships hold. Attributing control to one or
|>the other "thing" in the description is a matter of *choice* -- you choose
|>the description that seems best fitted to your needs.
|
|Scarce aggreement if any on this from me.  You are an object, the pencil on
|my desk is an object, and so on.  These are not subjective views, you and the
|pencil have definite properties and attributes which work over you as a whole.

I'm not sure if we'd use ``subjective'' in the same way. I agree that the
thing you call a pencil has definite properties which belong to it-as-a-whole.
I agree that this entitles you to call it an ``object'' -- because it's an
appropriate descriptive technology to use. (Here, I'm using the informal --
lay-persons -- sense of ``object'', not the computational one.) But this view
is *abstract*, it's a way of carving up the world to make sense of our
perceptions; in that sense it *is* subjective.

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.

|Do you have a better point of view.  The functional one seems even further
|from reality to me but I do keep an open mind.  Do you have a convincing
|argument that there is a better and more natural way of viewing the world?
|I'm all ears.

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.

As for a better and more natural way of viewing the world, again, what do you
mean by ``better''? Better for what? And what does ``natural'' mean? There are
at least two views (ho!) on the latter:

-- Natural means ``what we're used to''. Heavens, different (programming)
languages have different natural idioms: for Pop, it's creative use of the
open stack, partial application, and properties; for Lisp, it could be
effective use of lists and higher-order functions; for Snobol it's the
exploitation of pattern-matching; for C it's, ur, pointers and address
arithmetic. The approach used in one language is completely unnatural in the
other. Nevertheless, each approach is valid in its language. In this sense,
being ``natural'' just means that it's a tool you know how to use effectively;
nothing to do with the real world.

-- Natural means ``appropriate to the real world''. Now, humans see the world
in a particular way, because they've been ``designed'' to fit into it at a
particular scale and using a particular set of senses. [There's a newsgroup
for discussing what ``designed'' might mean here, and I don't propose we
side-track down that line here.] We've got cultural and generic machinery that
makes certain concepts seem to belong out there -- in the world -- rather than
in our heads. But our notions of natural *break down* when we start to explore
environments grossly different from those we grew up in; the very small, the
very large, the very fast, the very hot, the very cold. Quantum mechanics is
``natural'' for describing the very small, for example.

So I don't think that the human notion of natural coincides with the behaviour
of the real world. And our programs are not confined to the world which humans
find natural; X-ray crystallography and galaxy-smashing simulations are just
as proper subjects for computation as bank accounts and travel arrangements.
(Incidentally, note that a ``bank account'' might well be an object in a
program. Is there a ``bank account'' object in the real world? Well, yes, if
you realise that a particular organisation is just as real as a cup. But bank
accounts aren't ``natural objects'', they're invented ones, like theatre
bookings and your employment contract.)

|>Now, certainly the choice is not *arbitrary* -- it's nice if the description
|>is internally consistent, nicer if it also describes the kinds of things that
|>you want it to describe. But that doesn't mean that there's only one choice.
|
|Again, if I can show an objective reality such as: the universe is made up
|of objects and these objects have properties and attributes that are
|objectively discernable, measurable, and workable then there is only
|one objective, true description.

Yes, *if* you can show this. Since I think it's a false statement, I can let
you can deduce anything you like from it.

|>I've just ``give my cup a little push''. (I was taling to someone about
|>actions as objects, and how real they were, and this piece of idomatic English
|>just popped out.) It suggests that actions can be -- are -- objectified in
|>(some) natural language uses. Are they still not in the real world?
|
|No, they are not.  You as an object can push the cup.  If you design an
|artificial reality and can say ``give my cup a little push'' and it moves
|a little this is magic, not metaphor.

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
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?
Well, that's one view -- seems like magic to me, though. The magnetic field?
Yes, that'll do me -- but if only objects cam push, then the field is an
object. It's invisible, inaudible, intangible (except to the cup) -- not the
notion of object I would have thought was ``natural''.

The remark about artificial reality is, I think, irrelevant.

|In our minds we have a notion of push but it is based on all the ways all the
|different kinds of objects that can push other objects.  There must be a
|pusher and almost always a pushee for push to work because this is the way it
|works in reality.

The notion of push is an abstraction, like the notion of cup. The actual push
is real, as is the actual cup.

|>| In other words, there aren't little "pushes" floating around but there are
|>| stacks that one can push an object onto.
|>
|>Your stack is just as much an abstraction as my push. Stacks don't come with
|>little labels saying "I am a stack" (although I suppose that they would if
|>they were International Rescue equipment); we call them stacks because they
|>relate in a particular way to the rest of the world.
|
|But there are stacks in the real world and there are not "pushes".

Ie, you do not admit that decoupling the notion of ``push'' from ``pusher'' is
a fruitful one. This is not a matter of natural law. *I* think pushes are
real; I've been on the receiving end of several. I think magnetic fields and
smells are real, too, and I don't think the lay notion of ``object'' is a good
descriptive tool for them.

|>Oddly enough, the stacks I know of in ``real life'', the archetypal push-down
|>stack of restaurant trays, are incapable of pushing objects -- something else
|>has to do the pushing.
|
|Then you know how to push the tray.  I think you're arguing either the
|behavioral interface approach or the choice of interface.  If you want the
|stack to be more like the stack you're referring to then make it an aggregate
|of movable parts and then define the spatial relationships and dynamics of
|the system; it'll work just fine.

Yes, and there are no ``objects'' knowing what to do in this description; just
plain objects and relationships.

|Your argument sounds like a choice of interface argument; the behavioral
|interface can be viewed as merely a simplification or abstraction of the real
|physical system involved.

Exactly. It's an abstraction constructed according to chosen rules.

|And the aggregate parts do have properties and characteristics, too.  They
|should be part of their interface to the world and not separated as with the
|unencapsulated approach.

Sorry, I'm lost. Are we talking about tray stacks or programmatic stacks now?
And how come we've started talking about encapsulation -- a concept to be
applied to *descriptions*, rather than an object in the real world?

|>| The doer is clearly defined in the most natural way known to us.  If
|>| there is no object (entity or whatever) which is to explicitly carry out
|>| this command, then we could have:
|>
|>Now you are applying the terms of our world model (with intelligent agents
|>[which, I suspect, is a model we share, irrespective of its truth]) to
|>software concepts (``objects'') in a way you need to convince me is
|>well-founded.
|
|With VR this is trivial.

Sorry, I don't understand. What has VR (I presume ``virtual reality'') have to
do with the argument? If you are saying that VR *has* applied the notions of
intelligent agents, all that says is that the notions been applied, not that
it is intrinsically correct in other domains.

|Most other software domains also deal with or describe real world entities
|and therefore modeling these entities is the most important issue involved.

Real world ``entities'' like bank accounts, weather forecasts, contracts,
programs, screen displays, marriages, perhaps? Yes, modelling the world
is important in software development -- irrespective of whether the world, the
program, or the language in which it's written, are OO.

|Also please be careful with the term "world model".  In AI this is the model
|or context in your head and I don't think this is the way you're using it.

There's probably several different uses of the term ``model'' knocking around
in my note (and its predecessors); if I or the context don't disambiguate
successfully, I'm sorry.

Usually by a ``model'' I mean a (formal or informal) construction, which can
be manipulated in ways related to the real-world operations it models to
generate answers which are related in a similar way to the real-world results
of the operations.

By ``our world model'' I meant the model of the world which humans seem to
share. It's certainly in my head.

|>I don't need any references to reality. I have one here now :-)
|
|True, that is why OO and OO systems are so trivial to build.  Even better
|with AI.

If you find them trivial to build, then you have access to rather more design
and coding prowess than I can lay claim to.

|>Reality is more slippery than you seem to think. My analysis would have
|>``bearing on reality'' if it let me make (testable) predicictions about
|>reality that were (by and large) true. (``By and large'' because the world is
|>far too big for any computer model we build to catch everything.
|
|I don't see this.  I can break the real world up into objects even starting
|with atoms, subatomic particles, and quarks, and can work my way up to any
|object that has discernable properties, can you do so for your model?

Since were talking about a hypothetical analysis I might do, the answer is
unquestionably ``maybe''. But this break-up you mention; you'll put all of
this in the object-oriented code, yes? No? Perhaps you'll be content with an
abstraction that does the job well enough. So will I.

|> Probably no model contained *in* the world can model *all* the world.)
|
|Interesting claim, can you prove it?

If I could, I wouldn't have said ``probably''. Isn't it a standard
philosophical chestnut? A universal model *in* the universe would have to
contain a model of itself modelling itself modelling .... Well, the thing
*might* go to a limit. Without a convincing example, I wouldn't bet on it.

[about unnatural designs being harder to understand]
|You missed the point.  It is that if it is natural, then its more likely that
|someone else can understand it.  Its like what you said below but since
|there's no argument, I'll delete it.

But my point here is that ``natural'' is not a given.

|>It's certainly *a* way. It might (or might not) be an *excellent* way. But
|>it's not the *only* way, and it might not be the only *excellent* way. Decrees
|>do not establish truth.
|
|Actually, there's an incredible building amount of evidence that OO systems
|are more maintainable, hold up better over time, are easier to understand,
|etc.  Its the old style unencapsulated approach that seems to have failed
|miserably (the software crisis), no?

Oh, I've no particular argument that OO programs seem to have various
advantages over non-OO programs. But this could just as well be because they
are better organised internally (for example, with data-hiding -- a concept
not supported by the real world), rather than because in some sense they
``fit'' the real world.

Is a complex number an object? An angle? An integer? Are any of them ``real''
(choke)? Would you excude them from OO systems on this basis?

|>I don't understand what you mean, then. If we're talking about programs ``the
|>computer'' does *all* [modulo trivia about I/O handling, etc] the doing -- the
|>"objects" are simulated by the machine. Well, if it can simulate objects, it
|>can simulate operations, too, and all that describing this as "punting" does
|>is to say that you don't like it [and cast aspersions on one of Oxfords most
|>enjoyable activites, to boot].
|
|No.  In OO programs the objects carry out the operations; the computer is
|transparent.

Well, that depends on what level you want to look at, doesn't it?

|This is not so with your model.

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

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

|It can be used by any actor (object).  If anyone else needs to carry out an
|operation in the algorithm, the algorithm can specify that also with O.M....

Or with wahtever notation one uses.

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

|and by not including it as a parameter WE HAVE A BETTER MODEL with
|the O.M ... or even (O).M ... (implied receiver).

Yes, if it works, it's OK. But is that *necessary*? If I wish to model without
having distinguished receivers (as, for example, makes sense when doing
arithmetic on generalised numbers), why should I use this unbalanced notation
that makes one argument more ``important'' than the other?

|Again, discerning the doer is more clear AND more reuasable AND closer to
|reality.  Don't get this without discerning the receiver, huh?

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.

|>Perhaps I have mis-spoken; the messages are not the receivers, they are the
|>doers. You seem to be refusing to take actions as objects; well, that's a
|>choice. It may be a convenient and frutiful choice; well and good. That
|
|No, it has a bearing on reality since the objects in the artificial world
|are the actors, the computer is transparent.  This matches reality,
|your approach doesn't.

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.

Diversity seems to have done pretty well in biological (``natural'') systems.
Don't knock it.

|>doesn't make it the *only* choice, and I read your arguments as saying
|>``object orientation is not only useful, it's *right*''.
|
|But it matches reality.  If you have a better way of modeling and or
|simulating it speak up.  This functional orientation just seems much
|further from the truth.

I have, and I will; it is this; *use whatever techniques work*. You will find
that no one technique will do everything. (Except this one, of course.)

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

|>Well, "normal" OO languages (Smalltalk, C++, Simula) *do* only ``overload on
|>the first parameter'' -- that is, the action that is performed is determined
|>by the "message" and the (type of the) first parameter (the receiver), which
|>may in consequence be granted special syntactic status.
|
|Smalltalk does so because it is statically typeless and C++ is statically
|typed.  I consider both weak because of this.  And I'm not up on my
|Simula.  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.

|>Granted, the selected action may then perform further dispatch, if that's what
|>the programmer has written. But that's not something the language does *for*
|>you, whereas in CLOS the action is determined by the "message" (the generic
|>function) and, in principle,  (the types of) *all* the parameters.
|
|This is based on weak or contrived systems.

Sorry, don't follow -- what is based on what ``weak and contrived'' systems?
CLOS does *more* for you than normal OO dispatch, which is just a special case
of CLOS dispatch. I wouldn't have said that this made it ``weak'' or
``contrived''. Since it allows OO dispatch to fit into the same framework as
the run-time generalisation of overloading, I would have called it a
``powerful unification''. (The run-time costs have been addressed elsewhere.)

|>It's so obvious -- and it isn't true. Yes, it's obvious, and we [humans; I'd
|>not like to speak for the rest of the biosphere] are probably engineered to
|>see it that way. It's certainly a handy way to carve up the world, and it
|>works pretty well.
|
|No, I've declared it as an objective fact and have yet to see otherwise.

Your declarations tell us about your beliefs, but they don't make them true.

|>It works *so* well that we try to make things into objects at the least
|>provocation. Is a classroom an object? How about a university? A nation? A
|>solar system? A galaxy? A flock of birds? A river? A photon? A traffic jam? An
|>ozone hole? A county boundary? A code? A (real) window? An (X) window? The
|>*law* of gravity? The *force* of gravity? Magnetism? The aether? A
|>(mathematical) group?
|
|First, try your hand at virtual reality.  That will answer your question.

You think a simulated experience will answer questions about the real world
and our descriptions of it? Perhaps it will tell me about the VR designers
*view* of the world, but that's not what I was asking about. What VR
experience will tell me if magnetism ``is'' an object? Why couldn't a *real*
experience tell me the same thing?

Or do you mean I should *program* a VR system? Great, you want me to build a
model of the real world. rest assured that I will carve up said world in any
way I find convenient, and I might use objects (the programming language
constructs) to model various things in the world (such as magnetic fields, and
traffic jams). But then I might use numbers, or groups, or procedures. If you
turn round, and say, ``see! you used objects!'', because you call everything
in my programming language an object, well, that's your choice, but I think
the terminology would lack precision.

|If you don't base everything on objects you're a fool.

Why, how kind. [I gather from this Bob *did* mean that I should implement VR,
rather than experience it.] In other words, knowing hardly anything about my
programming capabilities, my scientific background, or the capabilities of the
languages and hardware I'd choose to use, Bob thinks objects would be forced
upon me. I disagree.

|And the rest of these examples are mostly concepts and abstractions like the
|kind we work with *in our heads*.

But are they *real*? (Of course they are. They're as real as Bob's objects,
anyway.)

|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.) So descriptions can contain
objects that don't appear in the world, right? And you're saying that magnetic
fields are only in our heads -- they're not ``out there''?

|For my own purposes I've broken the world up into transitory parts such as
|real-world modeling (RWM), mental worlds (MW), and abstract worlds (AW) since
|each has its own requirments and properties.  For RWMing its OO all the way
|and for the rest the same applies.

I'm sure you can bend the OO style to fit, but I bet I wouldn't find it
``natural''.

|>What sends messages to a mass to tell it to exert force on the floor?
|
|The universe enforces universal laws in my book.

So, where you can't find an object, you attribute the messages to the
universe? Where are the messages? I must admit that treating the universe as
an object is a neat trick, considering that the universe is itself an abstract
concept. Can you point to the universe (not just to a bit of it)?

|>What sends messages to ``1'' in ``1 + 2'' to tell it to compute ``3''?
|
|Define the ring of integers and export its operations (like Ada's use clause).

Yes, yes, that's programming, I don't want to know how you'd *write* it, I
want to know what sends the messages. *I* think that the object ``+'' is sent
the message ``run(1,2)'', and that (because all the operators take the one
message ``run'' with a pair argument) that perhaps there's another description
more suitable to the job.

|>Do I send messages to my cup when I fill it with tea?
|
|It does know something has come in contact with it.  I like the universe
|idea myself for "dumb" objects and forces.

If you're taking ``the univer enforces universal laws'' as a base-point, there
*are* only *dumb* objects.

|>Is the object-oriented notion of "message" appropriate to cups, tea-bags,
|>waves (wet), waves (electo-magnetic),
|
|If it comes in contact, sure.  Physical dynamics are handled by the
|universe with objects at various levels receiving the various forces.

The forces are messages? But, since the forces themselves to messages, then
messages must be objects too.

|It gets more interesting with us because our senses input these forces
|on contact and then interprets them using trellises and other wonderful
|things.  I'd love to go on but my time's up and way past due.

Trellises?
--

Regards,    | ``Wandering minstrels are fogging my brain    | Judy Tzuke
Kers.       | And weird intellectuals are doing the same.'' | Higher & Higher