Re: Copy and initSeed

[Rick Riolo]

re the initSeed:
I guess I was thinking of the Gaussian class (vs the uniform) when I 
was talking about directly setting the distribution's seed
with initSeed...sorry for the confusion.
I think the Gaussian objects have the initSeed: method, yes?

re inherited copy:
Roger says 
   > There is no standard copy message inherited for all objects
I guess I am confused about why one can go up the hierarchy
using the go-up button in probes and eventually get to
the object class, which (in the probe) seems to have a copy method
(along with init,free,shallowCopy, and a bunch more methods)
which I can click on and then get a reference to a copy of the probed
Heatbug which I can then drag over and add to the heatbugs list.
Also, I just modified the heatbugs program, adding this little bit of 
code:
    if ( i == 0 ) {
        aCopy = [hbug copy];
        [aCopy setIdealTemperature: 200]; 
        printf( "\n just made the copy, its idealTemp is %d (parent's is 
%d).\n",
            [aCopy getIdealTemperature], [hbug getIdealTemperature] );
    }
to the loop in HeatbugModelSwarm.m that creates the heatbugs.
(I also added the getIdealTemperature method to Heatbug.m/.h).
This compiles and works, giving this output when it starts up:

 just made the copy, its idealTemp is 200 (parent's is 29530).

So....what I am confused about is where that copy method comes from.
I don't see one in Heatbugs.m/.h .  
As I said in my first message, I've not used the copy method before 
but I just assumed it would be there to make a copy of any object inheriting 
from SwarmObject.
Am I wrong about that?  Why does it work in Heatbugs?

thanks for clearing this up for me (and maybe others).
  - r

Rick Riolo                       address@hidden
Program for Study of Complex Systems (PSCS)
1061 Randall Lab     University of Michigan
Ann Arbor MI 48109-1120
http://pscs.physics.lsa.umich.edu/PEOPLE/rlr-home.html

On Mon, 2 Dec 1996, Roger M. Burkhart wrote:

> Date: Mon, 2 Dec 1996 18:11:28 -0600
> From: Roger M. Burkhart <address@hidden>
> To: address@hidden
> Subject: Re: Copy and initSeed
> 
> Benedikt Stefansson asks:
> 
> > And I was also under the impression that copy should be an inherited
> > method from SwarmObject, but it doesn't seem to be. 
> > 
> > If one of the hivemeisters has time to clear up this confusion I would
> > appreciate it...
> 
> There is no standard copy message inherited for all objects because there's
> no general rule for what should be considered part of an object vs. merely
> referenced by it.  (In some libraries the extent of an object is sometimes
> distinguished as a "shallow" vs. "deep" copy, but what those mean can be
> highly object specific, and must end up being specifically coded for each
> object type.) For some objects that are deeply entangled in references to
> other objects, it may not even be valid or meaningful to attempt to copy
> the object as a new instance.  (This is true of some schedule components,
> for example.)
> 
> What this means is that if you want a copy message, you can still provide
> one; we just don't provide any default inherited method.  You have to code
> what makes sense for your objects yourself.  For objects on which you want
> to support a copy operation, you provide your own copy method.  If we had
> multiple inheritance, we might be able to provide a way for you to
> selectively inherit a default copy method from another class when you want
> it, but since we have to bundle up all inherited methods into a common
> superclass, we don't provide it there by default.
> 
> If you provide a copy: method, you should use the [anObject copy: aZone]
> form suggested by defobj and followed by existing copy: messages.
> If you want to copy just the local instance variables of an object, and
> not anything it points to, the following method should work:
> 
> - copy: aZone
> {
>   return [[self getZone] copyIVars: self];
> }
> 
> We could bundle up this code in a function someplace, but since it's
> a single statement for now we just leave it for an implementor to provide
> if this stand-alone form of copy makes sense for your objects.
> 
> An argument could be made that this default method could be provided on
> SwarmObject for use by all subclasses unless overridden.  That would
> impose a burden on all subclasses to disable the method when it didn't
> make sense, however.  The times when the default method doesn't make sense
> can be surprisingly often, for example whenever the object contains
> pointers to other allocations that aren't guaranteed to be shared.  We
> avoid the potentially error-prone default in favor of being explicit about
> what copy action is supported you do want it on an object.  Objects should
> not be assumed to support copy: unless they specifically document that
> they support it, and even then they must say what exactly is copied when
> you call it.
> 
> Roger Burkhart
> 
>