Re: [ALACPP] Thoughts on last night's code sample

["Arlo Belshee" <arlo@xxxxxxxxx>]

> Again, event handler is a bad name. We were really using it for type-safe,
> auto-streaming, tax-free RPCs.

Actually, Eventhandler was an excellent name for its original use. It's
original use did not become its primary use, however. In the site of primary
use, a type computer was used to de-generalize the EventHandler & to rename
it. Specific policies were chosen, and the type computer was named
NetIncommingFn.

The general use was as an event handler socket. An object could export several
EventHandlers, one for each type of event that it could fire. Then, listeners
could subscribe their handler implementations to the corresponding events, eg:

class Alarums
{
public:
  EventHandler0< >::type ClockStopping;
  EventHandler2< Time, HouseAddress >::type AlarmTriggered;
  // ...
};

void workerMaker(Alarums &al)
{
  Worker *someobj = new Worker(/* ... */);
  al.ClockStopping = boost::bind(&Destructor< Dingus >, someobj);
  al.AlarmTriggered =
    boost::bind(&Worker::putOutFire, someobj, _1, _2);
}

For this purpose, the name would perhaps have better been something like
EventHandlerChainSocket (too long). They aren't really events - they're places
to hold the set of registered observers of events. However, they aren't really
event handlers either - those would be the actual functions called (eg,
putOutFire). We never did find a good name that made us happy, so we just
called them EventHandlers.

After all, in the case of the EventHandler that supports only one recipient
(SingleEventHandler), there really isn't a lot of difference between the
instance of the event handler and the instance of the boost::function object
that it contains. There is more of a difference in the case of the
MultiEventHandler (event handler with append assign policy), as there is a one
to many relationship present.

> Given that we were simply using integer values for message identifiers,
> perhaps it would be possible to specify the integer value at compile-time
> as a template arg, in order to do some kind of checking? Some way that you
> couldn't mix-n-match handlers to the wrong events? To my knowledge,
> however, this never happened. No one ever decided to listen for A instead
> of B and A and B's arguments were the same.

We'd thought about doing this. There was a longish discussion; I don't
remember the reason that we decided not to. Part of it was that NetIncomingFns
were not really full classes of their own, but only type computers for
EventHandlers. EventHandlers have no concept of a message ID; that was only
added at the NetFn level.

Basically, EventHandlers served to provide a place to register delegates.
Incomming net messages were deserialized, and then transformed into events
(calls to the corresponding EventHandler), via lookup on the MessageID. The
EventHandler itself was completely unaware that it was involved in network
traffic (as were the delegate functions that it called): it just knew that an
event had occured, and the args were on the stack. Among other things, this
made it really easy to test: only the outermost tests had to involve a network
at all.

Network sends didn't use EventHandlers at all: they just had an
auto-serialization based on the template args for the appropriate
boost::function. As there was no double-blind dispatch involved, there was no
use of EventHandler.

Arlo
_______________________________________________
alacpp mailing list
alacpp@xxxxxxxxxxx
http://lists.ellipsis.cx/mailman/listinfo/alacpp