Re: [Boost-users] problem... maybe boost could help

From: Nat Goodspeed (ngoodspeed_at_[hidden])
Date: 2007-06-21 15:14:53

> -----Original Message-----
> From: boost-users-bounces_at_[hidden] [mailto:boost-users-
> bounces_at_[hidden]] On Behalf Of Lukasz
> Sent: Thursday, June 21, 2007 1:56 PM
> To: boost-users_at_[hidden]
> Subject: [Boost-users] problem... maybe boost could help
> 
> If anyone has some brilliant idea as to how this can be done (if it
can),
> then i would appreciate the input.

[Nat] No such thing around here, just a half-baked thought.

I wonder whether it would make any sense to introduce, for a given event
subclass type, a canonical filter listener object. For a simple event
class hierarchy, it might even work to register such listeners in a new
map keyed by the typeid().name of the event subclass.

So any receiver can look up any specific filter listener in a central
registry. Each filter listener itself contains a registry of dependent
receivers who want to process the events it's willing to pass. Its own
processing method dynamic_casts each event to the desired event subclass
type, and forwards only successfully-downcast events. 

Let's say we have receiver class SomeReceiver with a method that wants
to process only EventTypeA events (processEventTypeA()), and another
method that wants to process only EventTypeB events
(processEventTypeB()). The SomeReceiver constructor looks up the
canonical filter listener for EventTypeA and registers
bind(&SomeReceiver::processEventTypeA, this, _1) with that filter
listener. Similarly for processEventTypeB().

The filter listener could be a template class, and the registry through
which they're looked up could use find-or-create logic to instantiate
each specialization of filter listener on demand. That way you wouldn't
need to maintain a central list of instantiations.

So it would be up to the receiver's self-registration code to decide
whether it wants to handle all events or only some subclass. If it wants
to receive all events, it registers with the central event dispatcher as
now. If it wants to receive only specific events, it registers instead
with the filter that forwards only those specific events.

Filter listeners, of course, listen to the central dispatcher. Or if you
want to get fancy with the event hierarchy -- let's say EventTypeA and
EventTypeB are each subclasses of EventTypeABBase -- I suppose you could
register the filter listeners for each of EventTypeA and EventTypeB on
the filter listener for EventTypeABBase. That way the filter listeners
for EventTypeA and EventTypeB impose less overhead because they only see
EventTypeABBase events.

(If you combine this idea with a fully generic filter-listener template
class and on-demand filter instantiation, the filter listener for
EventTypeA needs to know enough to register itself with the filter
listener for EventTypeABBase. It's not yet clear to me how to automate
that. I guess you could hand-specialize the filter listeners for
EventTypeA and EventTypeB so they'd know where to self-register.
Alternatively, it's not strictly necessary for the EventTypeA and
EventTypeB filter listeners to register on the filter listener
EventTypeABBase -- that just appeals to my sense of elegance. They could
all be neighbors on the central dispatcher.)

I hope this will at least prompt other people to contribute more
sensible ideas... ;-)