Re: [boost] Simple object factory: Checking signatures at runtime

From: Marco Costalba (mcostalba_at_[hidden])
Date: 2007-09-07 07:23:16

On 9/7/07, Dean Michael Berris <mikhailberis_at_[hidden]> 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' ?

-----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...

> 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.

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.

> 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...

Thanks
Marco