DBs and Events

[s001gmu at nova.wright.edu]

On Wed, 11 Feb 1998, Greg Munt wrote:

> On Tue, 10 Feb 1998, Nathan Yospe wrote:
> 
> > On Tue, 10 Feb 1998, Greg Munt wrote:

[caching etc...]
 
> > :Any references to Event Management? Is there any alternative to using a 
> > :pointer to a function, to store the Event->function()? (This has the 
> > :disadvantage of every Event->function() needing to have the same number 
> > :and type of parameters being passed to it.)
> > 
> > Here we go. This I can help you with. Events don't have to be functions,
> > for a start. An event could be stored as anything, from a script on down
> > to a held thread. I store mine as classes... any action is executed from
> > an event class, which grabs the nearest available execution thread, sets
> > it to the event's references, and frees it to go. Events are, by design,
> > only actually capable of grabbing one specific thread, such that any set
> > of events cannot execute asynchronously on the same resources. Functions
> > are actually pulled up _after_ execution begins... Event.Process() is at
> > its basis a normalization check, which tries to match a list of objects,
> > and upon success, changes the values of the objects to a new norm, then,
> > with its still-active thread, allows those objects to update. The object
> > update methods are the actual functions involved, and once each object's
> > updates are complete (and affected objects with zero delay complete such
> > updates as the modified objects have made available) the thread is wiped
> > clear of variables, set to sleep, and returned to the pool. 
> 
> I'm not sure I understand this too well. Are you suggesting this?
> 
> class Event
>   {
>      private:
>        DataType1 *a;
>        DataType2 *b;
>        ...
> 
>      public:
>        ...
>        process();
>   };

I don't do things exactly the same way as Nathan, but my approach is
pretty similar.  Events work pretty well when done as Classes, I think.
 
> I still can't see how the event isn't a function. The tasks that the 
> event does have to be stored in a function?

well, when you get down to it, what the event does HAS to be in a function
somewhere.  What he was saying (I believe), is that you don't necessarily
have to have a struct with a function pointer in it, limiting the type of
functions that can be assigned.
Classes are not really much different, but because of data encapsulation
it's a lot cleaner to get around the limit on the # of paramaters to the
event handling function.

> Am I wrong in thinking that the data that an Event needs (eg pointer to a 
> Player) are stored in the class, with a function - which takes no 
> parameters - calling class methods to do whatever it is that the Event is 
> trying to achieve? Also, it looks like Event would need to be a template. 
> Forget that, am using Linux g++ :(

you are correct in assuming that all relevent data should be stored in
the event class.  You are incorrect in assuming that the event class has
to be a template class.  I suppose you could do it that way, but I think
it'd be a lot cleaner if you just descend a bunch of event sub-classes
from the base event class.  Each sub-class would have a different set of
variables, and it's own version of the event.process() method.  The event
driver only need know about a very limited subset (if not just one) of the
event classes.

what's wrong with linux g++, as far as templates go, btw?
haven't had a need for a template class yet, but then I'm not very far
into things.  :)
 
> I'm free of Cobol now! Hurrah!

heh.  I've never touched COBOL, and if I can help it, I never will.  :)

-Greg