Re: Building objects on the fly

[glen e. p. ropella]

Jae Chan Oh writes:
 > Thanks, Glen, that's what I'm doing now. So nice to be able to make sure 
 > that what I'm doing is right. :-) 

Well, Swarm needs people to absolutely tear it apart and use
it for things it was never meant to do and in ways it was never
meant to be used.  Even though it's now "out of beta," so to 
speak, it's still a bit of a virgin package.  What you're doing
isn't quite "software testing;" but, the more you veer away 
from what you see in the demos, the closer you get to that.

 > In my simulation, the Model Swarm does not know -- at least not directly --
 > about births of individuals.
 > The simulation is like people running around in the world, if it happen to
 > bump into a likable person, they mate -- therefore, each person only
 > knows about birth of its child, much like the real world situation.

Good.  It actually seems best if the modelSwarm doesn't know all
the details of the populations in it.

Also, a word of caution: I realize that it helps to use metaphors and
such; but, you may want to watch your usage of phrases like, "like the
real world situation."  I do it all the time....but, I'm not trying to
model real systems, at present.  [grin]

I'm going to point out small things that might be relevant in the 
pseudocode.  Don't take these comments as criticism of your method,
which I think is OK.

 > -mateWith:  (id) person      // person is ptr to the person I want to mate 
 > with
 >   {
 >   Person * child;
 > 
 >   // some stuff deleted 
 > 
 >   // OK, NOW generate a offspring
 >   child = [self createChild];
 > 
 >   [[child getPersonDNA]  Mate: [self getPersonDNA]  And: [person 
 > getPersonDNA]
 >                          withMutation: MUTATION_RATE];
 >  return self;
 > }

It's interesting that you instantiate the child THEN setup it's 
genome.  I would think this would more properly be done during 
the creation process of the child (i.e. between the createBegin 
and createEnd for the child).

 > -(id) createChild
 >  {
 >     Person * child;
 >     child = [Person createBegin: [self getZone]];
 > 
 >     ..... setup some stufF
 > 
 >     [child setPerson: id];   // create dna, set-up something...

I don't understand what this one means, unless you're using "id"
as a placeholder.... This has to be pseudocode.

 >     // tell the child where she is
 >     [child setWorld: pplPresent World: world ReaperQ: reaperQueue];

The setWorld:World:ReaperQ: method might better be named something
like setWorld:Space:ReaperQ:.  Repeating the word "World" kinda
makes it look like you're setting the world twice or you have 
two kinds of world, or something.

In the original hello-world, the "world" actually was the list
of the people at the party.  The "room" was the space they were
walking around in.  And the "party" was the Swarm of which they
were a part.  This isn't a great way of doing it, and, again, you
should back off and re-examine how you want to divide your world.

 >     ..... setup some stufF
 > 
 >     // finish the create phase
 >     child = [child createEnd];
 > 
 >     // add the child to the list of people
 >     [pplPresent addLast: child];
 > 
 >   return (id) child;
 > }
 > 
 > 
 > And in setPerson
 > 
 > -setPerson: (int) n
 >   {
 >   iD = n;

Typo, I assume?  I don't understand this at all.  Above,
you sent the string "id" as an argument to "setPerson:", which
I took to be pseudocode for the idea that you would be passing 
some, heretofore unknown, object into this method.  But, here 
it looks like you intend to pass an integer into this method.

Also, even if you change it from "setPerson: (int) n" to 
"setPerson: (id) n", it's still highly obfuscating to use a 
variable called "iD" to represent an object.  (I'm assuming you
would have declared "iD" as being of type "id".  The way you
used this method makes me think this should look like:

-setPerson: (id) n
  {
    id someObject;

    someObject = n;
[...etc...]

 >   numOfFriends = 0;  // no friends made so far
 >   live = TRUE;          // yes, it has just born
 > 
 >   //  create Chromosomes etc
 >   dna  = [BinChromosome createBegin: [self getZone]];
 >   [[dna setLength:  (int) (GEN_LENGTH/8)] setRandomInit];
 >   dna = [dna createEnd];
 >   [self setEvalFuncFromModel];
 > 
 >   return self;
 >   }
 > 
 > 
 > Do you see anything wrong in the above code? 

Except for the comments above, it looks workable!  (Don't forget
to declare "dna". ;-)

 > Also one more question about your code below...
 > What is myParentSwarm? Can I use [self getZone] instead? That's what I'm
 > doing. Whenever I need an object whether the new object is logically
 > belongs to another object -- like in the case of Person object and
 > Genome Object above -- I get a new Zone using [self getZone] message.
 > Is it OK? I thought about using [dna getZone] but that doesn't seem to work.

Yeah, that's fine.  I probably shouldn't have used that.  But, this
is a new feature that Roger added for Swarm 1.0.  It's called 
"swarms as zones".  Basically any Swarm can be used as if it's a 
Zone.  So, if you have objects that you want to create and place in
a Swarm *and* that object belongs ONLY or PRIMARILY to that Swarm, 
then it makes perfect sense to use that Swarm as the Zone (which is
the idealized as the region of memory in which the object resides).

But, [self getZone] is fine, and more applicable in the general 
case.  (WARNING: This is a matter of opinion and should be taken
as such. [grin])

Also, "[dna getZone]" should work.  If it didn't, then that might
mean that you did it at the wrong spot or something.  Any class
inheriting from DefObject should accept this message.

 > > Now, there should be some message that the modelSwarm can 
 > > accept to tell it to add the new person to the appropriate
 > > lists and the space and such.  But, the creation of the 
 > > individuals should be abstracted from the system you're trying
 > > to model.
 > 
 > Well, as I said above, I add new persons in Person.m. Do you mean that
 > I have to let the ModelSwarm know about the adding the new Person explictly
 > using a method? Since the pointer pplList is known to both ModelSwarm and 
 > Person objects, wouldn't it reflect the changes in pplList from the 
 > ModelSwarm's
 > view if we change the pplList in a Person object?(i.e. adding a new Person)

In general, you should make a decision about what controls the contents
of the world, space, lists, etc.  If all the modelSwarm does is walk 
the lists and execute methods on everything in those lists, and the 
agents inside the Swarm are responsible for adding and removing themselves,
then *no* you won't need to explicitly let the modelSwarm know when
a person is added or deleted.  But, if you allocate control over these
lists to the modelSwarm and the modelSwarm is supposed to be responsible
for adding and deleting people from the list, then *yes* you should 
have a method on the modelSwarm that the people can call.

This is a "modelling" problem.  It's NOT a programming problem.
You're best bet is to step back and ask "What is the role of the
modelSwarm?"  and "What responsibilities does it bear with respect
to maintaining the world?"

If the "atomic unit" (i.e. the smallest object dealt with) for the
modelSwarm is the list and the entire Swarm and all it's functions
and actions are related to lists, then I would say it's perfectly 
ok if the modelSwarm doesn't keep track of the individuals that are
a part of it.  But, if the modelSwarm, at ANY point, knows and 
manipulates the individuals resident on those lists, then not explicitly
giving the Swarm control (or accounting info) of the contents of 
those lists is inconsistent in a modelling sense.

 > Thank you very much for your help!

No problem.  That's what Chris is paying me for. [grin]

glen