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