// SimpleCBug

                FROM C TO OBJECTIVE-C


This is an Objective-C  version of the simpleCBug program.
The code for the "bug" has been encapsulated in an "object",
defined in the two files Bug.h and Bug.m.

--------------------------------------------------------------

main.m

main.m has new code to "create" a bug, to set its internal
state, and to tell it to execute  - to "do its thing." We 
communicate with the "bug" by sending it "messages", using the 
syntax: [id message args].

So,
             [aBug setX: xPos Y: yPos];

is a command to send the object "aBug" the message:

     `set your X and Y coords to xPos and yPos'

The message [Bug create: globalZone] is asking the Bug "Class"
to give us an instance of a Bug, which we thereafter refer to
as "aBug". The message [aBug step] is asking the object "aBug"
to perform it's major action, taking a random walk - but the 
code for doing so is hidden from us here. We just ask it to 
"step" and it does it, whatever it is.



Bug.h and Bug.m

Object are implemented in two files each. The "Interface" and the 
"Implementation" files (".h" and ".m" files, respectively.) 

The ".h" files declare what internal variables an object has and 
what messages it will respond to.  They are called "interface" files, 
because they declare *what* the object will do, without stating *how* 
they will do it. In principle, nobody should care how the object does 
what it does, they only need to know what it does. 

The ".m" files are where one specifies *how* the object will respond 
to the messages defined on it. 

In this case, the "bug" object has four internal variables: xPos,
yPos, worldXSize, and worldYSize. It has three different types
of messages that it will respond to: setX:Y:, setWorldSizeX:Y:, and
step. All of the parts followed by colons (:) are considered to
be part of the message name, while the bits inbetween (x and y here)
are the arguments carried along by the messages. 

Thus, on the basis of looking at the Bug.h file, we can tell that 
this Bug object can be asked to set its X and Y coordinates
to specific values and to set its idea of how big its "world" is.
It also can be asked to "do its thing" - whatever that is, by
sending it the "step" message,

By looking at the Bug.m file, we can see how it does what it does. 
The "methods" that are implemented here are pretty much just what 
was done in main.m before, just seen from the other side of the object 
interface.  Thus we set X and Y coords, fix the size of the world, and 
take a step in a random walk.

The object "uniformIntRand" is a random number generator object
in the Swarm library, which will return a random integer in the
range specified by rMin and rMax. In this case, it will return 
either a -1, 0, or 1, uniformly distributed. It takes the place
of the random_move() helper function in the simpleCBug application.



Makefile

Here, we have two binaries to be linked: Bug.o and main.o, and
the linkage and recompilation dependencies are as shown.


Running the model....

  This model should behave just like the simpleCBug model.



NEXT -> simpleObjCBug2
