Re: [boost] Assign V2 - first impression

Subject: Re: [boost] Assign V2 - first impression
From: Christian Holmquist (c.holmquist_at_[hidden])
Date: 2011-06-24 12:04:36

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.

> 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:

Then I think you have not read my response, or I fail to communicate with
what I've said from beginning.
-> I cannot understand the code you are producing with the help of your
library <-.
Even if I read the documentation it's still a mystery.

>
>
> "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.

>
> 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());

> 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.

> 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.

- Christian