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

From: Dean Michael Berris (mikhailberis_at_[hidden])
Date: 2007-09-08 04:35:34

Hi Marco!

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

Yes, but I meant it in a higher level of design -- why you would want
to refer to an object instance through a reference to the base type
and *then* cast it to a derived type.

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

Which actually makes sense, to the effect of:

factory_pool<fusion::vector<base1_t, base2_t, base3_t> > pool;
base2_t * ptr = typename pool::template factory<base2_t>::object();

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

I'll look into the feasibility of different return types. Off the top
of my head, I'm thinking this should be possible, though would usually
be a bit more tricky than my initial assessment of the problem and
possible implementation(s). This is a good idea though, having
different signatures having different return types... :)

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

Yes, I should get to doing this pretty soon -- because I see a pretty
big use-case for this requirement in the current (professional)
project I'm working on.

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

I will explore allowing multiple return types definitely.

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

Because of the focus on type-safety, I don't think there's any way the
dispatcher can support many other signatures without having them
explicitly listed during a dispatcher's instantiation. If there was a
way to modify a type during runtime, then perhaps that'd be the day --
but since C++ remains statically typed and both statically/dynamically
polymorphic then I'll stick to having the types listed down at compile
time at type instantiation and prefer statically polymorphic rather
than dynamic polymorphic implementations.

So it will remain more or less:

dispatcher<fusion::set<void(int), void(double), void(std::string)> > d;

> >
> > 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 ;-)
>

Indeed. :)

-- 
Dean Michael C. Berris
http://cplusplus-soup.blogspot.com/
mikhailberis AT gmail DOT com
[phone]