Re: [boost] Dispatcher Library Initial Implementation

From: Alberto Ganesh Barbati (abarbati_at_[hidden])
Date: 2006-07-15 10:52:59

Dean Michael Berris ha scritto:
> Of course, both of these are optional, and there are default "dumb"
> routing and validation strategies that are by default implemented by
> the dispatcher
> 
>> 2) what it is the relationship between such features and the dispatcher?
>> I mean, index validation and routing are (to me at least) two concepts
>> completely unrelated to dispatching, so IMHO it would make much more
>> sense to have a generic container that could store any value type, not
>> only functions. Once you have such container, you can make a decent
>> dispatcher by just putting boost::functions in it.
>>
> Think of it as "message routing" if "dispatching" conjures up a lot of
> different things for you. For me at least, this is how I understand
> how a dispatcher works:
> 
> Someone (client code) refers to a person (dispatcher) and asks "can
> you please get me <index>?" -- the person (dispatcher) is trained to
> see if <index> is a valid index (validation) and normalizes/transforms
> the index (routing) to pull up the correct object/function requested.
> 
> As far as I understand it, if you don't need the validation and
> routing, then you don't need the dispatcher -- but in cases that you
> do need that, or a runtime switch replacement, then it should come in
> handy.
> 
> The goal of the dispatcher is to facilitate the registration and
> dispatching (or calling) of runtime functions, and providing a
> dynamically reprogrammable interface for such a facility. For certain
> problem domains, this appeals as a simple and extensible solution --
> in other cases, it might be overkill.

Thanks for the explanation. Your two hints about validation/routing
being optional makes me think that you think I am objecting those
concepts. Contrariwise, I do think the concepts of validation/routing
are interesting *per se*. Those concepts can of course be applied to
dispatching (or retrieving/calling runtime functions, or whatever you
prefer to call that) but have a much more general value, IMHO.

For example, here's my use case: I am writing a videogame and I need to
load a lot of texture images from disk files. Of course I don't want to
load the same image twice. A simple map where the key is the file
pathname is not a good tool, because there may be different pathnames
pointing to the same file. Let's assume that using some kind of
canonical form of pathnames is sufficient to uniquely identify the file.
So my "routing" step is a conversion from a pathname to its canonical
form. My "validation" step is a check that the file actually exists and
identifies a supported image format. See? A container like the one you
described could be very useful to me, yet I am going to store objects
which are not functions nor related in any ways to functions.

Does it make sense?

Ganesh