Subject: Re: [boost] [review] Review of PolyCollection starts today (May 3rd)
From: Joaquin M LÃ³pez MuÃ±oz (joaquinlopezmunoz_at_[hidden])
Date: 2017-05-15 10:12:30
El 14/05/2017 a las 22:33, Edward Diener via Boost escribiÃ³:
> On 5/2/2017 7:46 PM, Ion GaztaÃ±aga via Boost wrote:
>> Hi everyone,
>> The formal review of JoaquÃn M. LÃ³pez MuÃ±oz's PolyCollection library
>> starts today.
> This is my review of PolyCollection,
Thank you for your contribution!
>> - What is your evaluation of the documentation?
> I have mentioned previously that I think the documentation should be
> more specific about the types being used for the
> boost::function_collection. While an example is good, as in the case
> of the tutorial, and while a reference is good, as in the case of the
> documentation for the insert member function, I found the former to be
> too singular and special an example while I found the latter to be
> highly technical and therefore hard to understand in general terms. A
> better addition is simply to document in an explanation of ideas and
> concepts exactly what types the boost::function_collection entails. I
> assume it is any type which can be passed to std::function, but I do
> not know if it can be a std::function object itself. Saying it is
> "Function wrapping in the spirit of std::function" does not explain it
> adequately to me. Also since std::function ( or boost::function if you
> will ) represents any callable it would be nice to understand why the
> programmer would want to use boost::function_collection versus a
> collection of std::function objects.
Points taken, as we have already discussed them in the past days. I'll
try to improve docs
so as to make these aspects clearer.
(When you insert a std::function<Signature> object x, into a
it is x that gets copied/stored rather than its underlying callable
entity. This is so because
std::function lacks functionalty to recover the wrapped callable entity
knowing its type, observe std::function::target does not type erase:
is the main reason why function_collection<Signature>::value type is *not*
a std::function, but an internall lookalike with the required extra
>> And most importantly:
>> - Do you think the library should be accepted as a Boost library?
> I think the library should be accepted based on the fact that it
> offers an alternative to normal collections which can prove valuable
> to end-users, and that it is a polished library with few surprises.
> With that said I think the library should document better the
> advantages and practical situations that make polycollection superior
> to normal C++ collections, else an end-user will be puzzled about for
> what situations it will be useful.
JoaquÃn M LÃ³pez MuÃ±oz
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk