Re: [boost] [review][assign] Formal review of Assign v2 ongoing

Subject: Re: [boost] [review][assign] Formal review of Assign v2 ongoing
From: er (er.ci.2020_at_[hidden])
Date: 2011-06-22 11:06:26

On 6/21/11 10:16 PM, Lorenzo Caminiti wrote:
> Perhaps similarly, I red all v2 docs and compiled all the tutorial
> examples. However, I am not familiar with v1 and I decided that I
> needed to go back and study v1 in order to understand why v2 is
> better/more useful -- so I am reading v1 docs now :)
>

I accept the general criticism that the presentation is not clear. 
However, please refer to my message to Brendon and let me know if these 
clarifications are helpful.

As for why v2 is an improvement over v1, let me explain what motivated it

- First, there are two important functionalities in 1.0, container 
generation (list_of now called deque) and list-inserters (not called 
put) that I bridged together via a crtp class for better code reuse. For 
example, the proxy object (now called interpreter) returned by list_of 
has functions repeat and repeat_fun, but the list_inserter independently 
defines similar functions, if I recall correctly.

- Second, I've tried to look under the hood of v1 and see if more code 
decoupling could be extracted from it. In v2, data-generation and the 
modifier invoked to insert its result are orthogonal. This is seen under 
section Option in the tutorial. By parameterizing data-generation and 
the modifier it's possible to extend either arbitrarily. Modifiers are 
no longer restricted to the basic ones (push, insert ...), and by the 
way, list_of (from v1) only "knows" one way to insert elements, 
push_back, a restriction that is lifted for its successor, deque.

- Third, it's now the same interface for value container and pointer 
containers. In fact, all container categories share the same interface : 
put and csv_put<>().

- Fourth, trying to figure out conversion in Boost.Assign 1.0 taught me 
some very worthwhile idioms. However, I have tried to make the interface 
a tad simpler with a unique function convert<>(), rather than 
to_adapter<>() and to_container<>(). It is described here: 
https://svn.boost.org/svn/boost/sandbox/assign_v2/libs/assign/v2/doc/html/boost_assign_v2/reference/conversion.html#boost_assign.reference.conversion.convert

As regards to ref + chain, please refer to my previous messages.

In a private conversation, it has been suggested that a modifier option 
is not as intuitive as a function dedicated to a particular modifier. 
For example,

csv_put<I, push_front_>(cont, a1,…,aI, …, z1, zI);

is not as clear as:

push_front<I>( cont, a1,…,a1, …, z1, …,zI);

which I can concur with. It would be feasible to allow that as well, but 
it's going to cost more compilation time, at least under C++03. 
Naturally, this is mitigated by keeping headers separate for each 
option, push_front, push_back etc, as is the case under directory /std 
in v1. Finally, this cost can be drastically reduced (if I'm thinking 
right) with a small sacrifice to elegance:

push_front<I>( cont )( a1,…,a1, …, z1, …,zI); //

Thanks for your feedback, and don't hesitate to ask more questions.