Re: [boost] Assign V2 - first impression

Subject: Re: [boost] Assign V2 - first impression
From: er (er.ci.2020_at_[hidden])
Date: 2011-06-23 16:57:54

>>
>> Does Assign (1.0-2.0) begins to add positively to your well being?
>> Assume, further, that you have to do the same thing all over again, but you
>> have to drop the function altogether, and replace push_front by push_back.
>> Is it better to write a function or use Assign?
> You lost me here. Guessing wildly, I would probably respond "write a
> function" and you would say "use Assign".

Then there is no conflict between your view and mine, because Assign 
provides you the function to do just that.

>
>
>> As for 2.0, specifically, do we agree about *decoupling* of features (_r,_d
>> and push_front_)?
>>
>
> I don't know.  What is _r, _d and push_front_?
>

I usually leave the benefit of doubt when I don't know. As for _r, _d 
and push_front_, they were in the snippet I gave. Do you mean that you 
don't understand their purpose?

>
>> The same code above requires very minor modification if used with put()
>> rather than deque(), are we on the same page about *code reuse*?
>>
> ?

     csv(
         put( cont ) % _push_front % _d % _r,
         1, 10, 100, 1000
     );

The syntax is very similar to that of the previous example, which used 
deque. Each of put and deque rely on the same class template. Hence the 
claim of code reuse.

>
>
>>
>> Finally, let's say you want something other than repeat, that does not
>> already exits. You can write write a small class, that conforms to a concept
>> (ConceptModifier), and invoke two mere macros, and the job is done. Do you
>> agree about *open for extension*?

Absent a rebuttal, I take it you agree it is open for extension. Let me 
ask you: why would that not be an improvement (that benefits the user)?

>
> I get the impression that Assign V2 mixes too many features under one hood,

Two, under one hood:
1- Argument forwarding (to a produce a data-element)
2- A modifier, to put the data-element in the container

Each is specified with a template parameter. This is behind two out of 
the 3 claimed 'improvements'. The third one, code reuse, is that it is 
the same class template behind put() and deque().

> and on top of that uses an unorthodox ways of expressing itself. I feel that

Fair. Suggestions have been made to improve on that, and I see that one 
person endorsed them.

> assignment and algorithms should not be interleaved in this way.

Do you mean operator| appearing inside an algorithm, by interleaved? I 
already answered this.

> Skimming trough the docs and examples leaves me very puzzled. I've now spent
> a few hours on this library, but I've not been able yet to figure out the
> first code line from the docs
>
> cal | do_csv_put<2>( "jan", 31, "feb", 28, "mar", 31 ),
>
> The difference between do_csv, put, _put, csv_put in all forms are subtle to
> me.

If we can leave the advanced features aside for a moment we have 
something that is manageable:

put( cont )(args1...)...(argsn...);
csv_put<I>( cont, a1,...aI,...,z1,...,zI);

My familiarity has blinded me. I now know to make the distinction clear 
between the basic features and the advanced ones, and motivate each better.

> I think they all return a proxy object containing a conversion operator and
> a magic for_each member function, but I could be wrong.

English sentence: Put each element of range in cont.
Assign v2 sentence: put( cont ).for_each( range );

I'll try to think more about your concerns. Thanks for helping to look 
at this library with a new pair of eyes.