
Antiobjects - raganwald
http://en.wikipedia.org/wiki/Antiobjects
======
RiderOfGiraffes
Now I remember why this seems so familiar ...

I used a similar method to the pacman solution to make a simulation of
traffic. By modelling the road as well as the cars, I could measure the
distance between cars by having the road remember when a car last passed over,
and give that information to the next car that passes over. The simulation was
enormously simpler by modelling the road and storing information in that,
rather than just in the obvious objects - the cars.

In effect, cars left traces behind for the next cars to collect and process.
Distances between cars could be calculated simply by knowing the times of
transits and speeds of cars. Uncertainties needed to be taken into account,
but the road could also contain pointers/references to the cars that had
passed over.

In my case I distributed the simulation over 1024 processors and the messages
were explicit. I find object-oriented programming largely to miss the point.
As Alan Kay once said, the point was never the objects - it was always
intended to be about the messages.

Of course, that's a religious argument, and probably better discussed
elsewhere.

ADDED IN EDIT: I really ought to write up some of my experiences ...

~~~
BigZaphod
Rambling thoughts your comment triggered:

When we model position of things in code, we often put the position within the
thing being modeled - car, game character, window, etc. So you can do things
like: aCar.position - but I think that might be conceptually wrong and have
been thinking that for a long time but haven't had much chance to explore the
idea.

The idea of putting the responsibility for (eg.) location of each object
within the world into the world itself seems to fit better with reality, too.
After all, in our physical reality there's rules that "the world" imposes on
things within it. One big one is that only one physical object (atom or what-
have-you) can exist in a given location in space at a given time. Having the
location of an atom in space be stored in the atom itself would seemingly make
it a lot more difficult to make sure that rule goes unbroken and, arguably,
can't be how the universe works as we seemingly cannot "see" location encoded
within physical objects in our universe (that I know of). Therefore the
location of a thing is probably "stored" within the fabric of the universe
itself...

Anyway... If you write up your experiences, please post them to HN - I'm
betting they'd be interesting!

~~~
jrockway
_When we model position of things in code, we often put the position within
the thing being modeled - car, game character, window, etc. So you can do
things like: aCar.position - but I think that might be conceptually wrong and
have been thinking that for a long time but haven't had much chance to explore
the idea._

But of course, you can have this API and delegate the responsibility of
calculating the position:

    
    
       class Street {
           has 'cars';
           method add_car(){
               $car = Car->new( street => $self );
               $self->cars->add($car);
               return $car;
           }
        }
    
        class Car {
            has 'street';
            method position() {
                $self->street->position_of($self)
            }
        }
    

Now, given a random Car, you can still ask "$car->position", but the actual
calculation is handled by something else.

(The deeper issue here is how consumers of Car are not coupling themselves to
a particular position-calculation strategy. Change the storage of the position
value from the Street to the Car, and consumers are none the wiser. This is
the point of OOP.)

------
jrockway
This is not a new concept, but rather just exercising good programming
technique. If you are modeling a collection of elements, and the elements need
to be aware of themselves in relation to the other elements, then you need to
model the container.

A simple example is an array. You don't ask an array element for the array's
length or for the i-th array element; you model the container and let the
container do that.

------
bd
That's actually a quite common pattern in artificial life community (inspired
by real world behaviors from insects):

<http://en.wikipedia.org/wiki/Stigmergy>

<http://en.wikipedia.org/wiki/Ant_colony_optimization>

Also Sims had some "intelligence" embedded into objects instead of the agents:

[http://www.gamedev.net/columns/events/coverage/feature.asp?f...](http://www.gamedev.net/columns/events/coverage/feature.asp?feature_id=51)

------
davidmathers
This reminds me of Luca Cardelli's theory of objects:

[http://books.google.com/books?id=4xT3LgCPP5UC&pg=PA7&...](http://books.google.com/books?id=4xT3LgCPP5UC&pg=PA7&lpg=PA7&source=bl&ots=9FMwvzLe9M&sig=U3K5GwytAgpPWXi4ZwgI8EhJ3ac&hl=en&ei=nE4dS-
TsMI2VtgeS7O3lAw&sa=X&oi=book_result&ct=result&resnum=2&ved=0CA8Q6AEwAQ#v=onepage&q=&f=false)

According to Luca the correct way to think about objects is not as the
entities of the software model, but as the construction materials for the
software model. He uses the analogy of making a physical model of the solar
system. In your model the planets don't move themselves, they're moved by
gears, tracks, and motors.

So it could be entirely appropriate to think of the pacman board being made up
of tiles and those being true, properly understood, OOP objects.

I think he would say that _"The metaphor of objects can go too far by making
us try to create objects that are too much inspired by the real world."_ is
exactly how not to think about OOP in the first place.

------
RiderOfGiraffes
Looking at the pacman solution, there's a problem when two ghosts end up on
the same square, then they might tend to follow the same path, whereas
programming them as objects (and not anti-objects) you can include avoidance
strategies.

To get that from the scent-following, hill-climbing algorithm requires some
work.

~~~
ludwig
Yeah, because ghosts are physical corporeal entities that couldn't possibly be
in the same place at once :-)

~~~
joshu
I wonder if there's an upper limit to the number of cospatial ghosts...

~~~
glhaynes
Modern scholasticism! :)

------
panic
This duality shows up in fluid simulation as well:
[http://en.wikipedia.org/wiki/Lagrangian_and_Eulerian_specifi...](http://en.wikipedia.org/wiki/Lagrangian_and_Eulerian_specification_of_the_flow_field)

------
bham
This reminds me of a funny Cracked skit about the 1979 game developer's
conference wherein the birth of Frogger was reenacted. "Ok ok you are a truck
driver and you try to run over frogs crossing the road". "No, no, you ARE the
frog!" "Whoooa"

[http://www.cracked.com/video_16019_video-game-pitch-
meeting-...](http://www.cracked.com/video_16019_video-game-pitch-
meeting-1979.html)

------
bartl
A major difference between the Pacman ghosts as described here, and cars in
traffic, is that the ghosts will _always_ be able to smell the pacman, no
matter how far he is, and a driver in a car has a limited view on the traffic
surrounding him.

The latter (limited) is easier if you use objects for the cars, the former
(unlimited) is easier using antiobjects.

~~~
thomas11
You could have tiles forget the scent/roads forget the traffic. With each
simulation step, decrease it until it's gone after however long you want it to
be remembered. Then, ghosts would have to be somewhat near pacman, and cars
are only influenced by what goes on around them, not what happened a while
ago.

Of course, simulating the actual view of a driver, i.e., excluding things
behind the vehicle etc., takes a lot more work.

------
tome
I would be tempted to call these "co-objects" since they are in some sense
dual to your standard objects.

