Hi Marco! On 9/8/07, Marco Costalba <mcostalba@gmail.com> wrote:
On 9/8/07, Dean Michael Berris <mikhailberis@gmail.com> 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 +63 928 7291459