Swarm interfaces (was Re: Event's Parameters

[pauljohn]

Transfering thread from swarm-support to modeling. 

I have 2 topics, one triggered by the createCall post.  

1.  I wonder if I/you/anybody could create a method that handles
this behind the scenes.  If you give me any encouragement I
might try. Referring to Marcus's method :

>   FCall createCall () {
>     try {
>         Selector sel = new Selector (getClass (), "stepArg", false);
>         FArgumentsC creating = new FArgumentsCImpl (new FArgumentsImpl ());
> 
>         creating.createBegin (getZone ());
>         creating.setSelector (sel);
>         creating.addDouble (2.5);
>         return new FCallImpl (getZone (), this, sel,
>                               (FArguments) creating.createEnd ());
>     } catch (Exception e) {
>         e.printStackTrace (System.err);
>     }
>     return null;
>   }

I was thinking of a class in java that could have a method
declared like
so:

     encapsulatedAction (? aZone, Class x, String aMethodName,
Object[] inputs)

Now, to create this encapsulated action, the user has to tell
the zone, the class for which it is being created, a String with
the method name, and then an array of arguments which have been
wrapped in java objects.  The more I look at this, I think this
could be a class method in Selector.  

I do not understand the FArguments class, but I have looked
through and guess this might work.  Suppose the method
"myMethod" of aBug has are 3 arguments, an int, a double, and an
object. The user says:
     argList = new Object[3];
     argList[0] = new Integer[4];
     argList[1] = new Double[533.4];
     argList[2] = someObject;
 
     schedule.at$createFAction (0,
Selector.encapsulatedAction(self, getClass(aBug),
"myMethod",argList));
    
I want the user to pass arguments that are wrapped, and we can
get the class type of each argument from them when necessary.
Right?  Inside the implementation I could create the selector
and do the other stuff. It is befuddling to consider the
possibility that the user passes a variable, rather than a
constant like 2.5.  Maybe it is not workable, I'm only dreaming.
But if you think it is possible, I might see if I can make this
work. 

Here is pseudo code, which is worth nothing except to convey my
aim:

   public static encapsulatedAction (? aZone, Class x, String
aMethodName,
Object[] inputs){
    try {
        Selector sel = new Selector (x, "aMethodName", false);
        FArgumentsC creating = new FArgumentsCImpl (new
FArgumentsImpl ());
        
        creating.createBegin (aZone);
        creating.setSelector (sel);
        if (Object[] != null ) processArgs(creating,input);
        
        return new FCallImpl (aZone, x, sel,
                              (FArguments) creating.createEnd
());
    } catch (Exception e) {
        e.printStackTrace (System.err);
    }
    return null;
  }
}

    processArgs(FArgumentsC sel, Object[] inputs){
        for (i = 0; i < inputs.length; i++){
            ....oh, gosh. It is necessary to detect the
            type of input, and then call the right method
            from FArgumentsC, as in addInt, add Unsigned, 
            addObject, etc....
}

        

Maybe I wish instead the schedule class could take a Java method
object and an argument list instead of the FAction.  Hmm.  This
multi-language stuff is much more subtle/difficult than it
seems, once you actually try to use it....


2.  And, as if this was not enough, I have a ZoomRaster question
too. I have developed some space classes that I want to plug
into a ZoomRaster, but my classes don't implement the full
Grid2d interface.  From looking at Value2dDisplay, I think the
list of necessary methods should actually be relatively small:
getOffset, getLattice, getSizeX and getSizeY as well as the
macro discrete2dSiteAt(lattice,offsets,x,y).  What do you think
of requiring a "smaller" interface with just those methods for
objects referred to in the setDiscrete2dToDisplay in the
Value2dDisplay.m file?  That interface would be adopted by
Grid2d.

-- 
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-Modelling is for discussion of Simulation and Modelling techniques
   esp. using Swarm.  For list administration needs (esp. [un]subscribing),
   please send a message to <address@hidden> with "help" in the
   body of the message.
                  ==================================