Re: can't do addBug via probes in heatbugs anymore?

[glen e. p. ropella]

>I agree this is the right solution for heatbugs: it should have a copy
>message to make a simple copy of a heatbug.  The old copy message (from
>Object) is blocked because it didn't allocate the copy in a zone, the way
>all Swarm objects are supposed to be (real harm could result if an object
>tried to drop itself from a zone it wasn't really part of).  The solution
>is to make sure that a zone-based copy message is provided.  By providing
>a copyBug method that allocated in the same zone as the receiver, the
>application could spare you the need to provide an extra zone argument:
>
>- copyBug
>{
>  return [[self getZone] copyIVars: self];
>}
>
>I agree that this makes sense for heatbugs and that the application and
>probe document should be updated accordingly.

I don't agree.  From the standpoint of showing off how we can
walk up the class hierarchy and execute an inherited message,
then, maybe.....

But, from an aesthetic view, a bug shouldn't be responsible for
copying itself unless there is a specific behaviour in the bug
that calls for reproduction... I.e. it should be part of the
bug's modelled behaviour.  The essence of extracting modelling
issues out of an implementation (which is what Swarm is supposed
to do) is to let the user design the agent's behaviour in the 
modelling context only.  I.e. keep all the specific esoteric
coding/implementation detail as far away from the user as possible.

So, in that light, it's reasonable to put a -copyHeatbug: method
in the ModelSwarm, where the model administrative duties belong.
Now, whether we only use copyHeatbug and addHeatbug when running
interactively or not, is irrelevant.  But, at least its in the 
right place.

But, that doesn't mean we shouldn't provide a default override
of Object's "copy" function.  It's just that I don't think that
a model-specific thingamajig like a Heatbug should make up for
things lacking in the machinery.  

glen