Hi Marco, On 9/7/07, Marco Costalba <mcostalba@gmail.com> wrote:
On 9/7/07, Dean Michael Berris <mikhailberis@gmail.com> wrote:
I guess the problem the dispatcher is meant to solve is way different from what your object factory is meant to address. However, something like this comes to mind (assuming that the functionality of multiple signatures is already in the dispatcher):
struct my_type { typedef dispatcher<fusion::vector<my_type*(int), my_type*(int, int)>, std::string > registry;
Why fixed argument type 'int' ?
This is for example purposes only.
-----cut -----
// ... factory<my_type> my_factory; my_type * ptr = my_factory["my_type"](1, 1);
In this approach, the factory is type specific and the initialization of the factory falls on the actual type to be registered in the factory -- and is enforced at compile-time leading to less bugs that will reach runtime.
It's ok to be type specific, actually I have a factory for each base class, as example
Factory<Base> will be able to create all the objects derived from Base while Factory<Base2> is needed to create objects derived from Base2.
So type specific on the return type is not an issue because of dynamic polimorfism allows user to up cast to needed type:
Base* p = Factory<Base>::get_object("Derived");
Derived* d = dynamic_cast<Derived*>(p); // perhaps not nice but it works...
Hmmm... I personally don't see why you'd want to cast down to a derived type when you already have a reference to the base type -- or why you'd want a reference from a base type when you really want a reference to a specific type. Yes, it's possible and allowed by the language but the utility (and logic) of this doesn't appeal to me personally.
I guess my reluctance to provide flexibility at runtime will limit the implementation of the dispatcher, which is intended to be as type-safe and static as much as possible -- whereas a goal of your object factory is to be flexible at runtime, which I don't see adds much value especially to the factory pattern because you'll need to know the types at compile-time anyway.
Well, you could have classes defined in different transaltion units, or in different libraries written by different authors in different times.
But how do these types register themselves to the "factory"? Wouldn't they (the derived types) need to know about the factory in the first place to register themselves? Or would external code have to do this -- but in which case why not just have the construction handlers mapped to an std::map<> and be done with it, or since any other kludge would be too involved, why not just custom Factories?
As example a library vendor could provide an object factory for their classes togheter with the library. Then a library user could register with the same factory the classes he writes subclussing the vendor's ones.
The object vendor factory does not know anything about the users ones and the only and sufficient constrain is that the user classes are derived from a base class on which the factory is instantiated.
So how different is this approach from using the dispatcher separate from all the libraries and just gluing them together for a custom "factory registry"?
I see that at this point our implementations will begin to diverge because the goals of our libraries are considerably different.
I'm not able to see so far ;-) I will try to follow your developments...
I think the divergence comes from my focus on static polymorphic implementations, while you would like to make runtime-polymorphic support the focus. Unless I'm wrong, in which I'd be glad to be enlightened. :)
Thanks Marco
Thanks for taking the time too. I'll try to follow your developments as well. I might pick up a few tricks as well for the dispatcher. ;-) -- Dean Michael C. Berris http://cplusplus-soup.blogspot.com/ mikhailberis AT gmail DOT com +63 928 7291459