CORBA, RMI, threads

[s001gmu at nova.wright.edu]

On Wed, 28 Jan 1998, Marc Eyrignoux wrote:

> Now I have a question for Greg: you told me my code should look like:
> > event_diver.schedule(new event(real_to_game_time(t)));
> But in this case, how do I know what the events refers?
> In the constructor, I only store the delay, but not the method that has
> to be executed when the delay will be attained?

How you handle events is pretty simple... simply write a handle() method.
the driver calls:

  event.handle(); // passing args if you feel it necessary

whenever the event's delay time has passed.  Just descend all the event
classes you need from the generic event class, each one overriding the
inhereted handle() method.  When you make the call to add the event to the
queue, you need to specify what kind of event, rather than the generic
event (the sample schedule call was used to demonstrate how to use the
time conversion function).  As far as the driver is concerned, it's
dealing with generic events and it doesn't care what handle() eventually
gets called (ain't polymorphism and late binding great? :)

So, to reuse my schedule example, you could have several different
calls like so:

  event_driver.schedule(new combat_event(real_to_game_time(t), attacker,
                                         defender));
  event_driver.schedule(new heal_event(real_to_game_time(t), target,
                                       amount));

etc.  Each event class descended from the generic event has it's own
handle() method.  You'll also want to have each descended event class's 
constructors take arguments of pertinent data, as above.  You can make the
inheretence tree as broad and deep as you like, depending on how you
choose to organize things.

<rant>
There are other ways of doing things which are less object oriented in
their design (like registering callback functions).  There is no one way
that your code "should" look.  Always keep in mind that there is no
"right" solution to any problem.  There are many solutions with varrying
degrees of effectiveness, based on your assumptions and understanding of
the problem.  Lines like "how should my code look" really bother me...
</rant>

 -Greg