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

["Jon Stewart" <stew1@xxxxxxxxxxx>]

> I don't know. Usually when I create events, I end up wanting to have
> behavior on them, or at least a discrete type. Things like
> serialization, etc. It just works better when they are discrete types,
> because even if I have a generic serializer I need to somehow


But defining serialization for an object is a big pain. We wrote 
serialization for all basic types, plus std::string and all the STL 
containers. With that done, we only had to write serialization for complex 
objects. Many of our messages were pretty simple, a token here, an IP 
address there, so a good deal of the time we didn't have to pay the 
serialization tax.

In fact, a substantial portion of our bugs were when someone added a new 
member to a class and forgot to stream it. By contrast, if you added 
another argument to send, you couldn't compile until you'd sent and 
received it.


> disambiguate between different kinds of events. You can use things like
> inheritence to do some clever event dispatching. You also have the
> benefit of actually knowing what all the events are in the system (nice
> use for typelist) in a really unambiguous way. The biggest reason though
> is it is just sooo much simpler (particularly when you are debugging),
> and I try to place some kind of a premium on XP's notions of KISS.


We used 2 byte ints for message IDs to disambiguate events coming over the
network. When a NetObject was created, it registered the IDs that it would
listen for. Perhaps a bit crude, yes.  OTOH, it was also simple, and quite
manageable using namespaces -- you could quickly get a list of all the IDs
by listing everything in namespace "Pkt" (we used sub-namespaces).

In our network topology, we had lots of different types of connections, 
depending on who you were talking to, and each type of connection 
typically had only a few messages it could send/receive. Those different 
types of connections were different C++ types, and that carried a lot of 
the type information that you'd normally get from having a big, generic 
event-handling system. It really wasn't a big, generic event-handling 
system. It was completely decentralized, so you weren't receiving an event 
from the central event-handling authority, you were receiving a message 
from Bob. And, hey, you know Bob, and Bob only knows how to say three 
things.

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

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.


> If you hate making event objects though, Boost PP sure makes it a lot
> easier to do argument-based events than any other solution (if anyone
> mentions varargs I'll kill them), so I'll concede that this really a
> question of design goals as opposed to the quality/correctness of the
> design.


Certainly. varargs sucks.


Jon
-- 
Jon Stewart
stew1@xxxxxxxxxxx
_______________________________________________
alacpp mailing list
alacpp@xxxxxxxxxxx
http://lists.ellipsis.cx/mailman/listinfo/alacpp