|
From: Nick C. <nic...@ve...> - 2002-12-30 19:32:03
|
Hi,
I agree with you on both the issue of adding isGui() and initSim() to
IController. In fact, my original IController had an isGui() in it. I
forget now why I dropped it.
However, I can see how something like isGui() or isBatch() can be used
polymorphically in DataRecorder. It receives an IController from the
SimModel.getController() and then behaves appropriately depending on the
result of isBatch(). What's less clear to me is how the polymorphic
initialization and running of a simulation would work. As it stands now,
SimInit creates either a BatchController or a Controller. It could
certainly treat these uniformly as an instance of an IController, but
considering that it needs to create either one depending on a command
line switch, there is little (although certainly something) to be gained
here. All this is not a criticism of adding something like initSim() but
rather a request for information on the benefits / the context of
polymorphic initialization. Maybe you've described this before in the
context of Jelly, but I don't recall.
Nick
On Mon, 2002-12-30 at 14:01, Mark R. Diggory wrote:
> I took ThinController and used it as an example, I also added the
> begin() method from BatchController to it (name actually called
> initSim()). This is because the begin method provides a transition point
> wherer the creation of the new thread occurs, making ThinController do
> alittle bit of thread startup management as well.
>
>
> I'm concerned about the multiple methods used to "initialize" the
> Controller under different IController implementations.
>
> 1.) display() is used in the GUI Controller
> 2.) begin() is used in the BatchController
> 3.) nothing is really available in the ThinController
>
> Would it be good to also have an "initialize()" style method that could
> be used to consolidate these different methods in IController?
>
>
> public void initSim(){
>
> 1.) in Controller this calls "display()"
>
> 2.) in BatchController this calls "begin()"
>
> 3.) a simple example in ThinController is attached.
>
> }
>
>
> I guess its a question of whether or not the setup should be done in a
> "Caller/Wrapper" or be done inside the IController. In this example it
> makes life easier in the caller. Given that BaseController is completely
> implemented in an asynchronous fashion, it is my opinion that
> Implementations that extend it should have at least some simple startup
> init like in display() (Controller) and begin() (BatchController).
>
> Maybe if non-asynchronous control of the sim were wanted (simulation
> runs in the same thread as the controller). Then thread management
> issues would be managed in the Caller of the Controller, in which case,
> the controller would be very simplified. Maybe one would have
> AsynchronousBaseController and NonAsynchronousBaseController
> implementations with
>
> Controller extends AsynchronousBaseController
> BatchController extends AsynchronousBaseController
> ThinController extends AsynchronousBaseController
>
> and
>
> SimpleController extends NonAsynchronousBaseController
>
> this example would move threading issues completely out into the Caller.
>
> These are just ideas, I'm sure of my opinion an this stuff, I'm not sure
> how valuable something like SimpleController would really be. It might
> be usefull in situations where Parallel Processing is managed externally
> to the Repast Sim, like in massively parallel supercomputer systems.
>
> Primarily, I think it would at least be wise to have something like
> initSim() in the IController.
>
> -Mark
>
>
>
>
>
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Repast-developer mailing list
> Rep...@li...
> https://lists.sourceforge.net/lists/listinfo/repast-developer
--
Nick Collier
Social Science Research Computing
University of Chicago
http://repast.sourceforge.net
|