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

From: Marco Costalba (mcostalba_at_[hidden])
Date: 2007-09-08 03:40:12

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

p->derivedOnlyMethod(); // compile ERROR!
d->derivedOnlyMethod(); // OK

> why you'd want a reference from a base type when you really want a
> reference to a specific type.
>

This is a Factory impelmentation limitation indeed the outher shell of
factory object creation function, the one that the user calls to get
an object: Factory<Base>::object() currently retirieves the correct
invoker/creator from the map and forwards the calling arguments.

The problem is this wrapper is instantiated with the factory, so can
only return a pointer of Base* type because it is the only class he
knows _when_ it is instantiated. This is due to deferred class
registering feature.

Only knowing all the classes that the factory will produce at the
moment the factory is instantiated could fix this issue IMHO.

In case of dispatcher you have only one return type for all the
functions you handle, also if with different signatures. If you relax
the constarin, as it is foreseeble, to allow covariant return types
for pointers to polimorfic objects, perhaps you will found the same
issue.

>
> > 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"?
>

Currently the dipatcher has the following design decisions that impact
a possible use as an object factory:

- Single signature function: already planned to be relaxed.

- Single return type: forces a factory to produce one kind of objects

- Signature list registration at dispatcher instantation: this forces
the user to know in advance all the signatures she will use at the
point of dispatcher instantation. I don't have the foresight to know
if can impact a library/user code scenario but for sure It's a strong
request.

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

Yes, I think the same, but I also think that having a good static
polymorphic implementation is a very valuable base from which to
adventure in the runtime world ;-)

Marco