Re: [boost] Assign V2 - first impression

Subject: Re: [boost] Assign V2 - first impression
From: er (er.ci.2020_at_[hidden])
Date: 2011-06-24 13:17:14

On 6/24/11 12:04 PM, Christian Holmquist wrote:
> On 24 June 2011 03:45, er<er.ci.2020_at_[hidden]>  wrote:
>
>> Thinking out loud, this would be easier to me (made up example):
>>>
>>
>> Before we switch topics, I'd like to summarize the last one, while not
>> closing the door to its extension, given that you promised me "more
>> feedback". Your initial concern, that I recognize as legitimate, can be
>> summarized as:
>>
>> Do the established design improvements ( code reuse, orthogonal features,
>> open for ext ) that I claim provide benefits the user, within the quite
>> narrow mandate of this library?
>>
>>
> You return to these claims all the time.Code resuse and extensions can both
> be part of a healthy design, but a library cannot stand on that ground
> alone.
>

About "return to these claims all the time". You have to understand that 
I don't really have other claims to make. The Formal Review Process 
invites, amongst others, these 2 recommendations : design & usefulness. 
I don't think I'm off topic.

>
>> To this end I compared a hypothetical sequence of unit tests using STL, to
>> another using V2. Pending your feedback, I have not seen a refutation, only
>> that "I don't know work a lot with copy 'n' paste", which does not rule out
>> that sometimes you come across something similar, or that someone else might
>> have to do such repetitive work. Mind you, V2 does not purport to be a swiss
>> army knife. Let me rephrase the narrow mandate:
>
>>
>>
>> "Its core utility is a compact interface for executing the repetitive tasks
>> of assigning or inserting elements in a container"
>>
>
> There is already a library that does this, Boost.Assign.
> You are proposing a library that, I think, does assign + transform +
> generate as one expression.
>

What do you mean by transform? Are you referring to ( _data = f )? In 
this case, you are mistaken : Boost.Assign's list_of and list-inserters 
have a mf fun to that effect. As for 'generate', deque() in v2 and 
list_of() in v1 are container generators. Or did you mean ( _data = f ) 
as generator? Based on this, v2 is no the upheaval you claim. Mind you, 
I studied v1 very closely to come up with v2.

>
>
>>
>> Even as I'm the one under scrutiny, today, I'm going to say that having to
>> study the documentation is not a receivable criticism. Having said this,
>> there is quite some leeway to rethink the interface to be more friendly. At
>> this stage, I would rather hear suggestions about "how", and thank Paul
>> Bristow for doing so.
>>
> I suggested how: Allow the user to use standard stl algorithms together with
> your library.
> It's a no win with this:
> std::vector<int>  v = magic_v2_expression;
> over
> std::vector<int>  v;
> std::generate_n(back_inserter(v), 10, generator_v2());
>

If I understand correctly, you preference is for the second statement, 
right? V1 and V2 deal with putting elements, either a) initialization or 
b) filling. I don't see elements, says x, y, and z, so it's hard for me 
to bounce back. Please clarify.

>
>> You do acknowledge that the "library can build complex
>> generators/converters of some kind", which has some good in it, I suppose,
>> but go on to criticize that "it's integration with the containers appears
>> ad-hoc.". First, please clarify "integration" since it has come up a few
>> times.
>
>
> With integration I mean the library should play nicely with standard stl
> concepts and algorithms.
>
>

I thought I started to do that by providing in place modification of a 
container with operator|, but you told me that you prefer separate 
statements : first fill a container, then pass it through an algorithm.

>
>> Second, your reasoning rests on hypotheticals (would): "The above would
>> allow me to only focus on how to configure the generators, and use my
>> old-time knowledge on how to use these with std::containers.". The proposed
>> library *is* in existence...
>>
>>
>> I take that as you are not interested in criticism then.
>

You misunderstood my point. I think I tried hard to respond to your 
criticism. First, there are gaps to fill in your suggested alternative, 
above, but please feel free to do so. Second, I don't think it's 
unreasonable to expect that the proposal be reviewed against things that 
already exist, such as V1. I have yet to see a Boost.Range + Lambda way 
to do the 5 unit tests that would challenge V2.

Having said this, I really thank you for initiating a challenge to give 
me a chance to prove that the design carries benefits for the user and 
appreciate that you are willing to try to move past first impressions. 
Whether or not you agree the code is more manageable, clear and safer, 
is a call that you can make without understanding the syntax. I should 
hope that if the answer is yes, it will trigger your interest for 
learning the syntax, which hopefully can be be improved.

> - Christian
> _______________________________________________
> Unsubscribe&  other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
>