Re: [boost] Review Request: poly_collection

Subject: Re: [boost] Review Request: poly_collection
From: Joaquin M López Muñoz (joaquinlopezmunoz_at_[hidden])
Date: 2017-03-02 09:41:25

El 01/03/2017 a las 23:15, Vicente J. Botet Escriba escribió:
> Le 01/03/2017 à 09:32, Joaquin M López Muñoz via Boost a écrit :
>> Hello,
>>
>> I'd like to ask for formal review of (candidate) Boost.PolyCollection 
>> [...]
>
> Hi,
>
> thanks for proposing this library Joaquîn.

Hi Vicente, thanks for your interest.

> I've surely missed why base_collection is named this way. Is it 
> because the parameter is a base class. Could you confirm?

Exactly. base_collection<Base> pretty much behaves as a container of 
Base objects.

> wondering if a single class with specializations wouldn't help
>
>     collection<polymorphic<T>>
>     collection<function<T(U)>>
>     collection<any<Concept>>
>
> In this way we could have
>
>     collection<Model, Allocator>
>
> BTW, I see that you have in the implementation a 
> detail::poly_collection<Model, Allocator> that is the base of the 3 
> collections.

This is mostly a naming issue. Indeed the three collections derive from 
the same
implementation and could be publicly provided as specializations of the 
same class,
if this is what reviewers lean towards. Personally I like it better to 
keep names
separated as in the current proposal.

> In your blog there were some comments about a collection of variants. 
> Have you considered adding a variant_collection<Ts...>

I've thought about it. Such a collection would deviate from the others 
both in terms
of its interface (no type registration, for instance) and implementation 
--the data
structure detail::poly_collection relies on could be used to support 
variants, but
more efficient implementations exist for this particular case.

> As the collections are closer to multisets (unordered/not-hash), maybe 
> it is worth using this name.

I'd say similarities with unordered_multiset are superficial (segments 
resemble
buckets) and the interfaces ultimately are too different. I chose 
"collection" because
the term is not overloaded in the STL or Boost.

> Have you think about using the same design for maps/unordered maps of 
> polymorphic objet (where the key is not polymorphic)?

Same-type contiguity is an essential feature of PolyCollection: I fail 
to see how this
could be preserved for an associative container. Care to elaborate?

> There is a C++ proposal for a polymorphic_value 
> (https://github.com/jbcoe/polymorphic_value/blob/master/draft.md). 
> Your base_collection<T> corresponds quite well to this 
> polymorphic_value<T>, isn't it?
> Maybe polymorphic_collection<T> or collection<polymorphic<T>>
> The main difference is the memory management, polymorphic_value can be 
> adapted to use an Allocator.

base_collection<T> behaves approximately as a 
std::vector<polymorphic_value<T>>,
the crucial difference being that the former groups elements by concrete 
type in
contiguous chunks of memory, while the latter holds indirection pointers 
behind the
scenes, so there is no real memory contiguity.

> What are the function types passed to for_each whee we have a 
> function_collection or a any_collection? Is a reference to the
> |value_type? |Do we need generic lambdas?

These functions are passed a (const) value_type&, where

value_type=function_collection_value_type<Sig>  for 
function_collection<Sig>,
value_type=any_collection_value_type<Concept>  for any_collection<Concept>

(see http://tinyurl.com/hmywnea , http://tinyurl.com/zh9ugl8 ). Now, 
when type
restitution is used (http://tinyurl.com/gopdpuz ), and only then, the 
functions are
passed a (const) Ti& for each of the restituted types Ti: in this case, 
a generic lambda
is a very convenient way of taking advantage of this, but you can also 
resort to a
polymorphic functor if you wish.

Best,

Joaquín M López Muñoz