Re: question about activateIn:

[Paul E. Johnson]

"Marcus G. Daniels" wrote:
> 
 
> Well, activateIn: is documented to return an activity.

I can't learn if I don't ask questions.  Sometimes your answer is "oh,
that was unnecessary" and sometimes you say "that's a mistake in the
swarmdocs" and sometimes you say "we really mean what we said there."  

> Because this is the intent, you can expect that we will write things
> in Swarm to depend on that behavior of activateIn:.  

I wonder if you couldn't do something to make the documentation easier
to decipher.  For example, could you put a protocol in the return type
to clue people in to the importance of the type being returned.  The
swarmdocs currently say this
- activateIn: swarmContext 

If the return is something that meets the Activity protocol, then could
this be written

-(id <Activity>) activateIn: swarmContext

I certainly think this is more clear.  I'm not denying that the paragrah
below says the return is an activity object, just asking about improving
the ease of use of the docs. 

> If you choose to
> write activateIn: according a different API of your liking (breaking
> the Sacred Contract Between User and Implementor) you can expect
> undefined results from the activity library.

I'm not thinking our contract is very sacred at the moment, but just put
yourself in my shoes.  Suppose a student writes this to me:

"why does it matter what is returned when the receiver does not "grab"
the activity?  For instance, if the receiver had this
     someActivity = [modelSwarm activateIn: self];
I could understand that the return in the modelSwarm's activateIn must
be 'return [self getActivity];'.   But since it is only this:
        [modelSwarm activateIn: self];
It should not matter."

I've been reflecting on this for quite a while, and here is what I think
might be the answer you would want me to give.

The method activateIn: is a Swarm Library method that users can
override. Suppose inside the Swarm Library, hidden to the user, there is
a call to activateIn:.  Suppose further that caller does "grab" the
output from activateIn:.  Since you have overridden the activateIn: in
your ModelSwarm, then your activateIn: method will be what gets executed
if the Swarm Library tells your ModelSwarm to activateIn:.  And if it
does not return an activity, you will get a bad result. 

That being said, I don't know of any activateIn: commands in the Swarm
Library that would serve as examples. 
 
> PJ> 3.  Also, would anybody care to put some words down on what comes
> PJ> back when you tell something to getActivity?
> 
> http://www.santafe.edu/projects/swarm/swarmdocs/refbook/swarm.activity.activity.protocol.html

OK, I'll put some words on it, you tell me if I'm wrong.

The thing called an Activity in Swarm would perhaps be better called an
ActivityManager, because that's what it is.  It responds to messages
like run, stop, next, terminate, and so forth.  This Activity(Manager)
object is what you get back when you tell a swarm to "getActivity." 
Hence, a construction like this will cause an object modelSwarm to stop,
because it sends the stop message to the Activity(Manager) of that
object:

      [[modelSwarm getActivity] stop];

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

In SwarmProcess, I find the method getActivity, which has this
description "getActivity returns the activity which is currently running
of subactivities within the swarm. This activity is the same as the
value returned by activateIn: when the swarm was first activated. It
returns nil if the swarm has not yet been activated."  

To me, the whole thing is befuddling.  The first sentence is puzzling
because of the phrase "of subactivities."   The middle sentence seems to
presuppose that all user activateIn: methods have at the end "return
[self getActivity]". Correct? If you assume that, of course, then the
return from "getActivity" and activateIn: must be the same.  But isn't
that rather a tautology?

It is unclear from the documention you refer to how the Swarm gets the
ability to respond to "getActivity" because the Swarm protocol does not
adopt SwarmProcess.


-- 
Paul E. Johnson                         email: address@hidden
Dept. of Political Science              http://lark.cc.ukans.edu/~pauljohn
University of Kansas                    Office: (785) 864-9086
Lawrence, Kansas 66045                  FAX: (785) 864-5700

                  ==================================
   Swarm-Support is for discussion of the technical details of the day
   to day usage of Swarm.  For list administration needs (esp.
   [un]subscribing), please send a message to <address@hidden>
   with "help" in the body of the message.