Re: [Boost-users] [review] Formal Fast-Track review of the Boost.Functional/Factory library - 2 days left

From: Tobias Schwinger (tschwinger_at_[hidden])
Date: 2007-12-21 11:28:16

Hello Nat,

thanks for reviewing the Functional/Factory utility and for the positive 
vote.

Nat Goodspeed wrote:
> John Torjo wrote:
> 
>> * What is your evaluation of the design?
> 
> "Factory" is a succinct shorthand for "constructor/new forwarding 
> library", but I must admit that the name Factory implies more to me -- 
> something more like the GoF Factory pattern.

Well, we have to keep in mind that the GoF book was written more than a 
decade ago. The abstract definitions of Design Patterns are pretty much 
timeless, however, the implementations in today's C++ can look different 
- even incomplete (details below).

> 
> I used the library to build a toy version of a Factory mechanism from a 
> previous project. With that, the client passes a std::string name and 
> gets a pointer to the corresponding concrete implementation of an 
> abstract base class.
> 
> To be sure, the messiest part of my previous implementation was passing 
> constructor arguments. It was nice that boost::factory eliminated the 
> need to handle that explicitly.
> 
>> * What is your evaluation of the implementation?
> 
> I didn't look at the implementation.
> 
>> * What is your evaluation of the documentation?
> 
> It could be more tangible. As I read it, my question was: how can I use 
> this library to build the functionality described above? To me, the most 
> useful part of the documentation was the hint about boost::function and 
> the examples.

If we want to create derived classes from an abstract base, 
boost::function needed. But is this isn't the only way to implement the 
Factory Patterns, is it?

If we want to create just objects that fulfill a certain concept we 
don't need boost::function at all. Note that the Patterns' definitions 
still hold - it just isn't all spelled out; the concept is not 
formalized in the programming language and so the need for a Factory 
base class and the implicit upcast of the Product vanishes as well.

So, it pretty much comes down to that OOD Patterns look different when 
they're applied at generic level. Also note we're not tied to class 
level granularity anymore, e.g:

     class some_class
     {
         // ...

         // Observer Pattern (all what's left of it):
         void register_observer(function<void()> observer_function);
     };

It's much nicer than the traditional GoF code, isn't it? We have both 
eliminated the coupling and the boilerplate code!

> Several more examples would be great. I'd particularly like to see the 
> boost::function trick illustrated in more depth, e.g.: here's a 
> std::map<std::string, boost::function<Base*()> > which we can populate 
> with boost::factory<SubclassOne*>(), boost::factory<SubclassTwo*>(), etc.
> 
> Since (to me) the real power of boost::factory is that it forwards 
> constructor arguments, extending that example to show a non-empty 
> canonical constructor argument signature (e.g. a mapped_type of 
> boost::function<Base*(int)>) would be good too.
> 
> But lack of that extended documentation shouldn't be a showstopper.
> 
>> * What is your evaluation of the potential usefulness of the library?
> 
> It's a very useful building block.
> 
>> * Did you try to use the library? With what compiler?
>>    Did you have any problems?
> 
> I tried boost::factory with Apple's g++ 4.0.1. I had no problems.
> I didn't try boost::value_factory.
> 
>> * Do you think the library should be accepted as a Boost library?
> 
> Yes. My one concern is that perhaps the name boost::factory should be 
> reserved for a later, more full-featured library, built on this one -- 
> though I haven't yet thought of a more descriptive name for this one 
> that's both clear and concise.

My personal feeling towards a more full-featured 'boost::factory' is 
that it will be either overly simplified or a tool to break a butterfly 
on a policy-based wheel...

Regards,
Tobias