On 24 June 2011 03:45, er <er.ci.2020@gmail.com> 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