1. OOP Question
I'm putting together this game, and I'm curious about the best way to go on
something... Ralf, you may have some particularly relevant insight on this
considering your PixelBot work...
The players will be controlling pieces on a board. There are two ways to
track their position:
1. The GAME object or PLAYFIELD object monitors/tracks the piece position,
and the pieces query the playfield object for their position, OR
2. The PIECES monitor/track their own position, and the GAME object or
PLAYFIELD object queries the piece for its position.
The first one is what I'm thinking is best, because the pieces' position is
irrelevant outside the context of a playfield!
The second one just doesn't sound right, but maybe I'm missing some logic
here.
Any helpful insight is appreciated.
-ck
P.S. I've got it set up so the game itself is an object, within which you'll
find a playfield, pieces, players, etc... all interacting in the environment
of the game.
_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com
2. Re: OOP Question
- Posted by George Henry <ghenryca at HOTMAIL.COM>
Nov 24, 2000
-
Last edited Nov 25, 2000
Tongue-in-cheek suggestion for an OOP solution (fufills the letter of
OOPness, if not the spirit):
Create an "Omniscient Programmer" object, and have all the other objects
that need to "know" the position of the pieces query the programmer as to
their whereabouts.
Seriously, I think that position is logically an attribute of a game piece.
Of course, position is relative to the playfield and the game and everything
else in the universe, but each piece "has-a" position that is uniquely its
(unless your game allows two pieces to occupy the same position; maybe I
should write, "characteristically its" -- then again maybe not, 'cause
that's too hard to type...).
What active part does the board (playfield) take in a game, unless the board
has wormholes that randomly appear and transport pieces to other positions
on the board? Pieces, on the other hand, do lots of interesting stuff like
move (change position), capture one another, etc. depending on the rules of
the game.
To change position, a piece needs to "know" its current position and the
rules that determine where it can go next. Its position, seems to me, is a
fundamental characteristic. Hmm, it's like my position at my job. I know my
position. The rules prevent me from becoming president of the company
tomorrow, or from suddenly deciding I want to be the janitor; But I could
make a sideways move to a comparable position in another department, or an
incremental upward move under aprropriate cursumtances. So I (an actor in
the dynamic life of the company, as I conceive of a piece being an actor in
a game) will not try to make a move that violates the rules, based on a
clear knowledge of my current position.
I hope this helps?
George Henry
Computers save time the way kudzu prevents soil erosion. -- Al Castanoli
_____________________________________________________________________________________
Get more from the Web. FREE MSN Explorer download : http://explorer.msn.com
3. Re: OOP Question
- Posted by "Fam. Nieuwenhuijsen" <nieuwen at XS4ALL.NL>
Nov 24, 2000
-
Last edited Nov 25, 2000
> I'm putting together this game, and I'm curious about the best way to go
on
> something... Ralf, you may have some particularly relevant insight on this
> considering your PixelBot work...
Well, the Pixelbots are not OO structured. It had the positions tracked by
the bot itself using service routines from the library, but I must admit
that storing their positions as part of the playfield makes much more sence.
Ralf N
nieuwen at xs4all.nl
4. Re: OOP Question
"George" (if that's your real name),
> I hope this helps?
Is that a question?
> I think that position is logically
> an attribute of a game piece.
And I've considered this, but then what would you do? Have the PLAYFIELD
query the piece... "Where are you?" The playfield should know where "its"
pieces are!
> ...each piece "has-a" position...
Say a piece has a position of { 6 , 9 }. That is totally useless
information. However, say a PLAYFIELD has a piece on { 6 , 9 }. Now you've
got relevance. So, who manages the position? I still believe it is the
playfield's.
However, remember there's a third object here- the "god" object (no
offense). It manages EVERYTHING. This "game" object is composed of a
playfield and pieces. Maybe the GAME object manages the positions, TELLING
the playfield AND the pieces where they are in relation to each other.
Maybe I'm just thinking too much.
Anyway, the three options:
1. The piece manages its position - now you have the playfield asking the
piece where it is. "Where are you?"
2. The playfield manages the position of its pieces - now you have the
playfield telling the piece where it is. "You are here, what do you want to
do now?"
3. The game object manages the position of the pieces on the playfield.
"You, piece, are at {6,9}. Did you hear that, playfield?"
> What active part does the board (playfield) take in a game,
> unless the board has wormholes that randomly appear and
> transport pieces to other positions on the board?
> Pieces, on the other hand, do lots of interesting stuff like
> move (change position)...
I submit that the piece doesn't move (itself), but GETS MOVED. I think it's
a crucial difference, no?
> capture one another...
Again, a piece doesn't capture, it is captured.
> To change position, a piece needs to "know" its current
> position...
You assume that "position" is a property of piece... I can see it being a
temporary storage variable, but the piece itself does nothing with it except
to remind the playfield where it is... thus eliminating the need for the
playfield to store the positions.
> and the rules that determine where it can go next...
Now this is something with which I agree (grammar gymnastics!)... or do I?
Imagine this:
You have a bishop piece. You have a chessboard CB1 and another chessboard
CB2. CB1 rules stipulate the bishop moves diagonally (ah, normality). CB2 is
a bit twisted and stipulates the bishop moves horizontally/vertically! You
have the SAME PIECE yet two different movement rules, as defined by the
PLAYFIELD. Do you see where I'm going?
So, it is not the piece that determines its movement, but the
playfield/gameboard/RULES OBJECT.
> Its position, seems to me, is a
> fundamental characteristic.
Nope, because a piece can be nowhere. It is only within the confines of a
playfield or rules system that a piece "acquires" any positional relevance.
Therefore, it is the piece that is told where it is, it does not tell where
it is.
> Hmm, it's like my position at my job.
> I know my position. The rules prevent
> me from becoming president of the company
> tomorrow, or from suddenly deciding I
> want to be the janitor...
A-HA! You've just validated my position! It is the RULES that determine the
move value, NOT THE PIECE. <whew> Thank you.
> But I could make a sideways move to a comparable
> position in another department, or an
> incremental upward move under aprropriate
> cursumtances.
Well, just as the rules allow that, you can also become a janitor, if ya
wanna.
> So I (an actor in the dynamic life of
> the company, as I conceive of a piece being
> an actor in a game) will not try to make
> a move that violates the rules, based on a
> clear knowledge of my current position.
Wrong, you will NOT BE ALLOWED to make a move that goes against the rules,
no matter how much you try. And you only know your position as you query
your environment...
> I hope this helps?
Most certainly! Thanks.
> Computers save time the way kudzu
> prevents soil erosion. -- Al Castanoli
What's kudzu again?
(I know, I know... look it up.)
-ck
_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com
5. Re: OOP Question
Hi, ck (if that's your real name 8^) ),
I wasn't trying to argue, I was just trying to help you clarify things. If
your opinion differs from mine, that's extremely cool -- after all, it's
YOUR program we're discussing.
If you want to know my true personal opinion, it is an extremely relevant
and pointed argument against OOP, which OOP itself creates, that issues of
this sort arise and steal hours of people's thinking time when they could be
doing more meaningful design or implementation work.
Maybe (just maybe) AFTER I get the whole thing working via procedural
programming, I can then intelligently REdesign something like this,
assigning the responsibility for carrying particular bits of data and
initiating particular actions to certain classes of objects. But all too
often, I see actions being performed ON a group of things, that make little
or no sense outside the context of the group. (As you point out, a game
piece has a position and moves [or is moved] only in the context of the
playfield.)
So what performs the action? The "program" object, which OOP really tries to
exclude and pretend does not exist, does it TO the complex of data
structures that are meaningful in the context of the program. Period.
Gymnastics and gyrations that force you to pretend that something else is
happening are doing nothing but forcing an artificial and fundamentally
false view of the proceedings on the programmer, the program, and anyone who
tries to understand the program in the future. And I submit that anything
that does that is doing a disservice, rather than improving matters.
You refer to the "god" object. Same as the program object, or the omniscient
programmer as shey embody sheirself in the code (where shey, sheirself are
gender-neutral singular pronouns of my own invention). Sorry, but OOP is a
godless approach to programming, where every data structure becomes a
demigod, but a god is unnecessary; and if a program has a (created) god,
shey has strictly limited powers. More pointedly, shey has only powers that
are explicitly granted, in the same way that powers are granted to other
objects; and maybe that is a good thing, in the context of programming.
I am basically amused by this whole discussion from an abstract point of
view. On the other hand, maybe we all stand to learn form it, myself
certainly included.
You must realize that there's (necessarily) a big difference in our
viewpoints. You're in the middle of designing and programming something that
obviously means a lot to you. While I am in no way inclined to trivialize
what you're doing, my POV is more aloof, and I'm more interested in taking
an abstract view of the whole ball of wax.
Saying that, to me a playfield should be a "stupid" thing - in the sense
that, what does the playfield neeed to know, or be responsible for? Suppose
I want to write a program about astronomy. Planets, stars, and other bodies
have positions in space, and the rules of physics determine where they can
move to next. If I want to know the position of the Earth at 4:04 AM on
November 25, 2000, I am more inclined to formulate my query as
earth.position("2000:11:25:04:04") than as space.position("earth",
"2000:11:25:04:04"). I just don't see any sense in asking space where each
object is in relation to it. It's simpler (note, one less argument, since
position in *space* is the only position that's meaningful) to ask each body
where it is. So do I want space to "know" where a potentially infinite
number of bodies are at all times, or do I want each body to know its own
whereabouts, velocity, and trajectory? I think, the latter. Of course, the
whole situation is a lot less complicated with game pieces on a playfield,
my analogy is imperfect, and we're free to treat bodies in space and game
pieces on a playfield completely differently. However, to me this analogy is
somewhat persuasive, or at least it's a way of illustrating the approach to
your progblem that I would tend to take, were it my problem.
Now, if I were introducing additional coordinate systems, and positing that
that a body could have independent positions in different coordinate
systems, that would be a different matter. Maybe Earth has one position in
space, and a completely different position in hyperspace. But who cares,
unless Earth can hold both positions simultaneously? If so, then I could
query earth.position(hyperspace, time) or hyperspace.position(earth, time);
but if Earth can't be in both space and hyperspace simultaneously, then my
code would look more like this: earth.context = hyperspace; pos =
earth.position(time) -- where I am back to the simplicity of a single
argument and the sense of rightness that (to me) goes along with that
simplicity.
Kudzu is a vine that was imported into the US to help prevent soil erosion,
and proceeded (and is still proceeding) relentlessly to cover everything,
smothering native vegetation and creating a uniformly unattractive (unless
you *really, really* like the looks of kudzu) blanket over the landscape
wherever it has become established.
Astronomically,
George (my real name, which my parents saw fit to give me)
_____________________________________________________________________________________
Get more from the Web. FREE MSN Explorer download : http://explorer.msn.com
6. Re: OOP Question
'enry,
> I wasn't trying to argue, I was just trying to help you clarify things.
I know! I'm of the same spirit. An increase in knowledge is good far beyond
the stature of "rightness." I'm of the opinion that this is a mind-expanding
exercise that does little, if any, harm...
> If you want to know my true personal opinion, it is an extremely relevant
> and pointed argument against OOP, which OOP itself creates, that issues of
> this sort arise and steal hours of people's thinking time when
> they could be doing more meaningful design or implementation work.
I have had that thought pop into my head, as well. I don't think it's an
argument against OOP, I think it's simply an argument against simplicity. I
also believe that OOP allows one to leverage those hours spent. Once we have
defined the object, it is usable over and over again, ad infinitum, ad
nauseum, Nike ad museum.
> Maybe (just maybe) AFTER I get the whole thing working via procedural
> programming, I can then intelligently REdesign something like this,
> assigning the responsibility for carrying particular bits of data and
> initiating particular actions to certain classes of objects.
The procedural approach, then: explain it for a game such as chess. You loop
through various sub-procedures, such as "get_moves," "draw_board,"
"determine_winner_if_any," etc...
> So what performs the action? The "program" object, which OOP
> really tries to exclude and pretend does not exist...
This "program" object I have discovered and named, "Game_Object." It exists,
regardless of whether or not OOP wants to exclude or deny (hey, just like
the Creator God of the universe! But I digress...). In fact, without the
context of this "Game_Object," I don't see any way to truly model the game I
want to create! Sure, we can let the piece carry its current position, but
if we want to model real life, I think we have to let the Game_Object do it,
because IT is the object that knows the rules. Not even the playfield can
hold the rules, as was demonstrated with my previous illustration of the
bishop's changing role on a chessboard. The playfield and the pieces are
simply pawns in the Game_Object's universe.
> You refer to the "god" object. Same as the program object, or the
> omniscient programmer as shey embody sheirself in the code (where
> shey, sheirself are gender-neutral singular pronouns of my own
> invention).
For a second I thought it was a speech-impediment made manifest via
keyboard. Now I'm simply left wishing that's really what it was, instead of
political correctness. Ah, well. I'm male so what do I know? 
> Sorry, but OOP is a godless approach to programming,
> where every data structure becomes a
> demigod, but a god is unnecessary;
But didn't you state your belief in the god_object, despite OOP's denial
thereof? The god, it seems, is necessary! How else does OOP programming
work? Maybe I just don't understand.
> to trivialize what you're doing, my POV is more aloof, and I'm more
> interested in taking an abstract view of the whole ball of wax.
I'm actually as interested in the forest as I am in this tree. I'm doing
this as much for the benefit of the big picture as I am for the pixel. My
contemplation here will have its reward in my future as well as yours and EU
OOP.
I like the abstract view because it is interesting and stimulating... moreso
simply because I am NEW to it. I'm sure there are old-hat OOP guys 'n' gals
out there who are yawning at this whole thing (or non-OOPers like jiri who
are yawning as well). I appreciate their willingness to let this run its
course!
> Saying that, to me a playfield should be a "stupid" thing - in the sense
> that, what does the playfield neeed to know, or be responsible for?
Well, unfortunately, the pieces are stupid too. So, we've realized our need
for the Game_Object, to control these stupid objects, right?
> If I want to know the position of the Earth at 4:04 AM
> on November 25, 2000, I am more inclined to formulate my
> query as earth.position("2000:11:25:04:04") than as
> space.position("earth", "2000:11:25:04:04"). I just don't
> see any sense in asking space where each object is in relation to it.
For simplicity's sake, you are inclined to do so... However, whereas you are
desiring procedural simplicity, I am desiring an accurate OOP model, and
despite the fact that the space object would be one humongous object, my
viewpoint is that it should retain the position of the stupid objects that
reside within it.
> It's simpler (note, one less argument, since
> position in *space* is the only position that's meaningful) to
> ask each body where it is.
But, IMO, it's an inaccurate model, and therefore I choose to disregard it.
> So do I want space to "know" where a potentially infinite
> number of bodies are at all times, or do I want each body to know its own
> whereabouts, velocity, and trajectory? I think, the latter.
I think the use of "potentially infinite" constrains your thinking.
Disregard any current limitations of data storage... If you were going to
model it all, would the position of an object be obtained from the space
object, or would it be gotten from the floating rock?
/huh?start
An object can know, however, its velocity in relation to its facing... It
would not know its facing, but it would know if it was "moving to its left,"
"moving backward," etc., would it not? Therefore, trajectory could be a
property of the object. Wait. No. Then you have the playfield querying the
planet object for its position.
/huh?end
> Of course, the
> whole situation is a lot less complicated with game pieces on a playfield,
> my analogy is imperfect, and we're free to treat bodies in space and game
> pieces on a playfield completely differently.
Well, we simply add gravity rules to the "game_object" and, WHAMMO, the game
of space, where the (relevant for us) playfield is our solar system and the
pieces... well... anyway.
> Maybe Earth has one position in
> space, and a completely different
> position in hyperspace.
Imagine further defining the planet class, to include the name of the solar
system within which the planet resides, its neighbors, etc. Now you could
have
system("sol").planet("earth").neighbor(1) = "Venus" AND
system("sol").planet("venus").neighbor(1) = "Earth",
which is, in my book, a duplication of data and therefore BAD! IOW, you've
got the same data represented multiple times. Isn't that considered a "bad
thing" in database design/programming?
Remove that property from the planet and give it to, say, the system object,
and now earth and venus can ask, who are my neighbors, and get that data
from the same data source.
I don't think I did my OOP representation very well up there, but hopefully
you understand my intent. If any OOP-guru can shed light on the above, and
my horrific mangling of it all, please chime in.
> where I am back to the simplicity of a single
> argument and the sense of rightness that (to me)
> goes along with that simplicity.
Just to clarify, are you deriving your sense of rightness from the
simplicity, disregarding the accuracy of the model, or do you believe your
model is accurate, as well?
We don't disagree that the model you present is simpler- I think we disagree
on whether that model is accurate.
And we both question whether it matters.
-ck (my nickname, which my third-grade teacher saw fit to give me)
_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com
7. Re: OOP Question
On 25 Nov 2000, at 13:46, ck lester and Henry wrote things....
which i won't copy over again here, cause it would just be too complicated.
Cause i am exhausted, none of this may make sense tomorrow, but for
now, it does...
What if the solar system managed the interaction of the objects (planets),
and each planet had it's own data (gravity, dimensions, lifeform listing,
etc)? Since the path is based on interaction, the solar system can tell the
planets where they are whenever they ask. If the solar system wants to
know the planet's reflectivity, the planet should be happy to tell it, since
that is a planetary quality. The solar system could then find how much light
is reaching it, to see how brightly it shines, not all the time, but only when
someone has asked for that particular piece of data, otherwise you are
wasting time calculating useless data.
My manner of executing the universe would be a separate procedural
program for planets, and a program handleing the solar systems, and
another to handle the galaxies. Naturally, if the program can run with larger
granularity, run it all on one puter, time sliced. Alternative universes are up
for grabs.
Imho, the only reason to make it OOPish is if the real objects needed to
respond in real time asynchonously to external stimuli, which they don't.
Neither do they in chess. In fact, since, on one hand, the home pc is
timeslicing *everything* anyhow, you can't get realtime. On the other hand,
with increasing cpu speed, you can increase the rate of timeslicing
(decrease the allocated time granularity) and approach realtime. But since
it doesn't need regimented multitasking, i'd run it in dos. Every program i
have converted to win from dos has run slower, even if it was the only user
application running.
In chess, you have the player moving in human speed, shey announces
they shey wants the piece in the corner to move diagonally 2 spaces. The
god(dess) part of the application looks to see what's there to move, finds
it's a knight, looks up knight attributes, discovers knights can't move
diagonally, and tells the player to go read a book on chess. And the
modern puter can do all that, regardless of programming style, faster than
the human can reach across the board to touch the piece,, so that's a
semi-vote for procedural programming, that application sure doesn't need
an interrupt or on_win-msg to interact with the human. All the bits of code
for the pieces is recyclable too, if you simply change the name, legal
moves, and values for each square on the board,, and use the same code
for each place on the board. If you consider that the puter is the opposing
player and must dream up a good move to make, then the overhead of
OOP and time slicing is a significant time drain, and again, i'd go dos, with
procedural programming, and the heck with the multitasking overhead too.
As an aside,, as a teen, i could play against 6 *teams* at once, pretty
much real-time, and win them all. After the 2nd game, i beat the adult guy
who was teaching me the game, he never won another game from me. I
have a dos chess game now, and it beats me nearly every game, even on
the middle setting. Sometimes i wish i was a teen again.
Kat,
exhausted, mentally and physically, tonite.
8. Re: OOP Question
On Sun, 26 Nov 2000 00:17:59 -0600, Kat <gertie at PELL.NET> wrote:
>What if the solar system managed the interaction of the objects (planets),
>and each planet had it's own data (gravity, dimensions, lifeform listing,
>etc)?
This is what has been proposed... and I agree with it.
>My manner of executing the universe would be a separate procedural
>program for planets, and a program handleing the solar systems, and
>another to handle the galaxies. Naturally, if the program can run with
larger
>granularity, run it all on one puter, time sliced. Alternative universes
are up
>for grabs.
I like to program as though my application will be running on those
computers that make the "Matrix" possible... heh. heheh. <ahem>
Honestly, though, as applications become larger, procedural programming
won't cut it... or will it?
>As an aside,, as a teen, i could play against 6 *teams* at once, pretty
>much real-time, and win them all. After the 2nd game, i beat the adult guy
>who was teaching me the game, he never won another game from me.
I like! You ever play on Yahoo games or the Zone?
-ck, up much later than he should be.
9. Re: OOP Question
On 26 Nov 2000, at 1:33, Ck Lester wrote:
>
> I like to program as though my application will be running on those
> computers that make the "Matrix" possible... heh. heheh. <ahem>
Too bad Connection Machines Inc. went bust. I would love to get my hands
on one of those. They were bought up, but afaik they don't make `em like
they useto. With the speed of development in new cpu and motherbd
archetecture, building a big new multiprocessor box means it will be
obsolete by the time you get it finished and running. I recall one *big* IBM
puter, ~1000 Pentiums, 100Mhz(?). By the time the last board was
installed, they couldn't find any more of those cpus new. I can imagine the
Matrix, but i can't imagine how they chose a point at which to freeze the
puter hardware development. An evolutionary hardware stage can obsolete
the existing software, maybe that's how it would (could? did?) happen.
> Honestly, though, as applications become larger, procedural programming
> won't cut it... or will it?
Sure they will, if you don't listen to micro$oft. <ramble> What will get
harder is finding dos anywhere, and eventually it simply will fail in all date-
critical situations, since it really isn't going to be maintained. And so
programs you write for it won't have an audience. If you convert to linux,
you take on that added overhead of the multitasking OS, and the built-in
toys, such as inter-application msgs and on_events, become attractive to
use, making the code more OOPish. The only percived and touted
advantage OOP can offer is adding functions to a library when you don't
have the oem source code, and overriding it's native functions,, both of
which can be simulated with straight procedural coding, imo. </ramble>
> I like! You ever play on Yahoo games or the Zone?
No, i haven't. Two yrs ago, someone told me about a program to download
that enabled people to play each other, but i never found anyone out there,
not even the person who told me about it, and so i deleted it. No time now.
Barely enough time to write any code. 
(
Kat,
going to sleep now.
10. Re: OOP Question
This is a very interresting discussion and therefor I would like to give my
two cents.
You are discussing the fact that actor1's position are attributes of the
actor or of the playfield or of the game in general. The problem is, Actor1
doesn't exist. Actor1 is a set of positions, textures and controlling
routines.
Who am I ? Do I exist ? I'm merely a bunch of biologic cells existing at
some place in this world. So, if you are really discussing which model is
more accurate, than I wish to add to that list, that OO is not the way to
model things.
It is the simplicity itself that distuinishes between actors and playfield
classes. In fact, you couldn't easy write code that disguishes classes. Its
the whole label-way thinking, you're putting things in boxes. This is the
good, but also the bad part of OOP. Therefor I would say, that the problem
'the most realisitic model using OO' .. is inmpossible problem. The most
realisitic model is a context sensitive model, where each relation between
facts is a fact on itself, which also relations. Far more complex than
objects and their attributes.
The reason we choose to use OO so often, is because it is very close to our
languages. They too speak of attributes, and subjects, leading subjects,
etc. "The box fell." or "I gave the man a hat.". However, we can change the
basic classes and improve our structure on demand, when logic needs it to
make it work. Programs can't. So you need to make the right choices from the
start. If you wish to change the 'rules' of the playing field at some futher
state of development you be wise to have at least the change in positions be
determined by the playfield-object. (assuming the rules are also attributes
of the playfield object). On the other hand, if you wish to create actors
that behave differently, on the same playfield all the time, you would be
better off having the positions as attributes of the actors themselves.
To conclude, you can't really speak of a most realistic model, but you can
speak a more useable model for a particular purpose.
Ralf N.
nieuwen at xs4all.nl
11. Re: OOP Question
ck,
Very briefly, on simplicity vs. rightness: I believe that "Occam's razor" -
the simplest explanation or approach *that works* is nearly always best - is
a good rule of thumb.
I'm probably taking this slightly out of context, but I recall reading in an
enormous book on OOP that it's an indicator of good style, language design,
program design, etc. when generally speaking your method calls have at most
one argument. Take that for what it's worth.
I can't imagine a *valid* argument against simplicity, per se. I can imagine
arguments against oversimplifying; but I think making things unnecessarily
complicated is at least as bad, if not worse.
All of the foregoing are statements of general principles, rules of thumb,
and the like.
It's apparent that some other folks who have contributed to this discussion
have given it all deeper thought than I have.
There is no such thing as an "accurate OOP model," except in a relative
sense. You are striving for an optimum or best model, which is the thing to
do. Sounds like you're on the right track. No doubt your model will evolve
as you work on the project, but it helps to be headed in the right direction
at the outset, no?
On the idea of space (moer accurately, space-time) storing the locations of
everything -- all *particles* and quanta of energy -- why not? It's possible
that it actually does just that. Greg Bear wrote a novel, Moving Mars, that
explores (among other things) what sorts of feats we could accomplish if we
could access and *directly manipulate* that information. (Greg Bear manages
to easily persuade me to suspend disbelief, so I enjoy his books.)
George Henry
Computers save time the way kudzu prevents soil erosion. -- Al Castanoli
_____________________________________________________________________________________
Get more from the Web. FREE MSN Explorer download : http://explorer.msn.com
