swarm-support
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Protocols and OO-ness [was: Copy method]


From: glen e. p. ropella
Subject: Re: Protocols and OO-ness [was: Copy method]
Date: Thu, 13 Feb 1997 11:48:16 -0700

>     glen> Now, there's no *real* problem with this.  However, there is
>     glen> a model specification problem.  The universe is responsible
>     glen> for initialization of bugs but not for the cloning of bugs.
> 
> It's not. Bugs are responsible for their own initialization, through
> the proper method. What you are saying here is that constructors, or
> factory methods, really belong to the universe.

Yes, it is the responsibility of the universe object to initialize
a newly created bug.  The constructor (factory object) takes 
care of many of the lower-level actions that need to happen, like
memory allocation and, in our ability to specify special things
in the createEnd function or the special create: method.  But,
these do not usually constitute fully functional bugs.  For instance,
in heatbugs, we do the following:

    hbug = [Heatbug createBegin: [self getZone]];
vvvvvvvvvvvvvvvvvvv
    [hbug setWorld: world Heat: heat];
    hbug = [hbug createEnd];
    [heatbugList addLast: hbug];
    [hbug setIdealTemperature: idealTemp];
    [hbug setOutputHeat: outputHeat];
    [hbug setX: [uniformIntRand
                  getIntegerWithMin: 0L
                  withMax: (worldXSize-1)]  // random position
          Y: [uniformIntRand getIntegerWithMin: 0L withMax: (worldYSize-1)]];
^^^^^^^^^^^^^^^^^^^

All this is initialization of the bug.  And it is being done in 
HeatbugModelSwarm.m (the universe object).  Without this initialization,
the bug would exist (have been created), but it would be non-functional.

And in Mousetraps, we have:

vvvvvvvvvvvvvvvvvvvvvvv
        aMousetrap = [Mousetrap create: [self getZone]
                                setModelSwarm: self
                                setXCoord: x 
                                setYCoord: y
                                setGenerator: randomGenerator];
^^^^^^^^^^^^^^^^^^^^^^^

Granted, this is all being done in a special "create:" method
that is defined in the Mousetrap class.  However, the responsibility
for the arguments (the initialization) lies with the MousetrapModelSwarm.

This is the way things are set up.  And, in my minority opinion, 
this is how they *should* be set up.  But, in spite of the fact
that initializtion of the bug is a function of the universe object,
the cloning of a bug is seen as being a function of the bug!  Ridiculous!
(It's only not ridiculous if cloning itself is, in fact, part of 
the behaviour of the bug.)


>     glen> message specified as "- (id) copy;".  Can a protocol do this
>     glen> kind of mapping?  Or would it be necessary to create a
>     glen> method in the universe object that took the former message
>     glen> and reformulated it to send it to the bug argument?
> 
> Of course not, but a "Copiable" protocol could be created, objects
> that follow it forced to implement it. 
> 
> This is not such a big deal in C++: copy ctors are compiler-generated,
> if you don't bother to supply one; and they should be defined in any
> well-behaved class. Besides, they are not inherited, which forces you
> to supply a copy constructor, or copy method, everywhere in the
> hierarchy.

Interesting.  What do you mean "compiler-generated?"

glen


reply via email to

[Prev in Thread] Current Thread [Next in Thread]