[review] Formal Fast-Track review of the Boost.Functional/Factory library begins today
Hi all, Today starts the formal Fast-Track review of the Boost.Functional/Factory library. *Description* Factories are callback mechanisms for constructors, so we provide two function objects, boost::value_factory and boost::factory, that encasulate object construction through direct application of the constructor or operator new, respectively. These templates make other facilities that operate on function objects (such as standard algorithms, Boost.Bind, Boost.Function, or Fusion functional adapters) applicable to constructors. *Author* Tobias Schwinger *Download* Get it from here: http://www.boost-consulting.com/vault/index.php?action=downloadfile&filename=factory.zip&directory=X-Files& Read documentation online here: http://torjo.com/tobias/ What to include in Review Comments ================================== Your comments may be brief or lengthy, but basically the Review Manager needs your evaluation of the library. If you identify problems along the way, please note if they are minor, serious, or showstoppers. Here are some questions you might want to answer in your review: * What is your evaluation of the design? * What is your evaluation of the implementation? * What is your evaluation of the documentation? * What is your evaluation of the potential usefulness of the library? * Did you try to use the library? With what compiler? Did you have any problems? * How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? * Are you knowledgeable about the problem domain? And finally, every review should answer this question: * Do you think the library should be accepted as a Boost library? Be sure to say this explicitly so that your other comments don't obscure your overall opinion. Best, John Torjo - Review Manager - -- http://John.Torjo.com -- C++ expert ... call me only if you want things done right
John Torjo
Hi all,
Today starts the formal Fast-Track review of the Boost.Functional/Factory
library. [...] Hello, this is not a review, but only a compilation of some doubts and suggestions for improvement: 1. I think value_factory requires that T be copyable, even if copying is ellided through RVO. This requirement is not stated in the docs. 2. Maybe it's a good idea to have BOOST_UTILITY_VALUE_FACTORY_MAX_ARITY be automatically greater than or equal to BOOST_FUNCTIONAL_FORWARD_ADAPTER_MAX_ARITY, so as to make it simpler to forward adapt value_factory. Same for plain factory. 3. Just as planned for the forward library, it'd be good to let the lib use variadic templates and rvalue refs when available. Just my 2 cents, Joaquín M López Muñoz Telefónica, Investigación y Desarrollo
Joaquin, thanks for your feedback. Joaquin M Lopez Munoz wrote:
John Torjo
writes: Hi all,
Today starts the formal Fast-Track review of the Boost.Functional/Factory library. [...]
Hello, this is not a review, but only a compilation of some doubts and suggestions for improvement:
1. I think value_factory requires that T be copyable, even if copying is ellided through RVO. This requirement is not stated in the docs.
Yes.
2. Maybe it's a good idea to have BOOST_UTILITY_VALUE_FACTORY_MAX_ARITY be automatically greater than or equal to BOOST_FUNCTIONAL_FORWARD_ADAPTER_MAX_ARITY, so as to make it simpler to forward adapt value_factory. Same for plain factory.
I'm not sure I like to couple these components. It's not /that/ likely to forward adapt factories, after all: I suspect that the arguments will be most commonly fed either by a) a central facility that might as well use lvalues or b) Boost.Function (no rvalue-ness inside).
3. Just as planned for the forward library, it'd be good to let the lib use variadic templates and rvalue refs when available.
Yes.
Just my 2 cents,
Taking care of the pence for the pounds to take care of themselves :-). Regards, Tobias
--- John Torjo wrote:
Hi all,
Hello! I hope it's not too late to submit a review.
What to include in Review Comments ================================== * What is your evaluation of the design?
Simple enough to understand. And I'm fine with the name, too, as long as it's qualified with the Functional prefix.
* What is your evaluation of the implementation?
N/A
* What is your evaluation of the documentation?
A little too sparse for comfort. It's not so much that there are too few examples, but that they need to be more fleshed out, e.g. code before boost::factory v.s. code using boost::factory. With this type of format, not only do programmers see the syntactical benefits of using boost::factory, but they could also tell at a glance whether or not they can use it for the task at hand.
* What is your evaluation of the potential usefulness of the library?
It's easy to underestimate, especially without more fleshed-out examples. But for myself, I find it very useful. For example, when I get the chance to update my Automaton library (and upon acceptance of this library), I'll immediately replace my default_constructible_gen utility with value_factory. This leads to another generalized use case: value_factory can produce lazy default values/objects for Boost.Parameter-enabled arguments.
* Did you try to use the library? With what compiler? Did you have any problems?
No, N/A, and not yet.
* How much effort did you put into your evaluation? A glance? A quick reading? In-depth study?
The Christmas season hasn't given me much time to do more than a quick reading.
* Are you knowledgeable about the problem domain?
Yes.
And finally, every review should answer this question:
* Do you think the library should be accepted as a Boost library?
I vote conditional acceptance pending improvements made to the documentation examples. The library is named after a design pattern that not everyone knows about or may have a different understanding of--some programmers see factories as object managers that reuse objects rather than delete them for performance reasons--so I think some in-depth examples are extremely important for clarification purposes. Peter Dimov gave a good use case, and FWIW I'll try to help out as well. Cromwell D. Enage ____________________________________________________________________________________ Never miss a thing. Make Yahoo your home page. http://www.yahoo.com/r/hs
Cromwell Enage wrote:
--- John Torjo wrote:
Hi all,
Hello!
I hope it's not too late to submit a review.
What to include in Review Comments ================================== * What is your evaluation of the design?
Simple enough to understand. And I'm fine with the name, too, as long as it's qualified with the Functional prefix.
* What is your evaluation of the implementation?
N/A
* What is your evaluation of the documentation?
A little too sparse for comfort. It's not so much that there are too few examples, but that they need to be more fleshed out, e.g. code before boost::factory v.s. code using boost::factory. With this type of format, not only do programmers see the syntactical benefits of using boost::factory, but they could also tell at a glance whether or not they can use it for the task at hand.
Yes, that's pretty much what I figured from previous feedback.
* What is your evaluation of the potential usefulness of the library?
It's easy to underestimate, especially without more fleshed-out examples. But for myself, I find it very useful. For example, when I get the chance to update my Automaton library (and upon acceptance of this library), I'll immediately replace my default_constructible_gen utility with value_factory.
This leads to another generalized use case: value_factory can produce lazy default values/objects for Boost.Parameter-enabled arguments.
Nice one!
* Did you try to use the library? With what compiler? Did you have any problems?
No, N/A, and not yet.
* How much effort did you put into your evaluation? A glance? A quick reading? In-depth study?
The Christmas season hasn't given me much time to do more than a quick reading.
* Are you knowledgeable about the problem domain?
Yes.
And finally, every review should answer this question:
* Do you think the library should be accepted as a Boost library?
I vote conditional acceptance pending improvements made to the documentation examples. The library is named after a design pattern that not everyone knows about or may have a different understanding of--some programmers see factories as object managers that reuse objects rather than delete them for performance reasons--so I think some in-depth examples are extremely important for clarification purposes. Peter Dimov gave a good use case,
...spelling out the (not quite so) obvious, I guess.
and FWIW I'll try to help out as well.
You did (see above). Thanks for your review! Regards, Tobias
participants (4)
-
Cromwell Enage -
Joaquin M Lopez Munoz -
John Torjo -
Tobias Schwinger