On 7/15/06, Alberto Ganesh Barbati <abarbati@iaanus.com> wrote:
1) why would I want/need such features on a dispatcher?
This is a good question, and the answer would be "it depends on the use case". For index validation, an example would be if you were taking runtime input and using them as indexes, and you want to enforce that indexes be of a certain kind (or setting rules on what valid indexes should be). This would come in handy in case you were registering dynamically loaded functions to runtime values as indexes and want to make sure that the indexes conform to some convention (in cases where you're implementing protocol handlers, and the schema is dynamic like XML). For index manipulation/hashing/transformation/routing the case would be for "normalizing" the valid indexes (or even the invalid indexes). That means trivial stuff like rounding up numbers, generating an md5 hash, doing case normalization, and the likes can be decoupled from the actual dispatching. 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. HTH -- Dean Michael C. Berris C/C++ Software Architect Orange and Bronze Software Labs http://3w-agility.blogspot.com/ http://cplusplus-soup.blogspot.com/ Mobile: +639287291459 Email: dean [at] orangeandbronze [dot] com