Re: [boost] [local] Review (and resignation from review assistant)

Subject: Re: [boost] [local] Review (and resignation from review assistant)
From: Lorenzo Caminiti (lorcaminiti_at_[hidden])
Date: 2011-11-23 09:26:23

On Mon, Nov 21, 2011 at 11:44 AM, Andrzej Krzemienski
<akrzemi1_at_[hidden]> wrote:
>> > Ok, I am not sure if there are no better ways to write it in each
> variant,
>> > and I may be biased. I also didn't try to compile the examples. But it
>> > should give the potential users an overview of options they have.
>>
>> Yep. This highlights the verbosity well:
>
>>   for_each( vec.begin(), vec.end(), if_(empty(_1)) [_1 = "n/a"] );
>
>> vs:
>
>>   BOOST_CLOSURE_PARAMS( std::string & n ) {
>>     if( n.empty() ) n = "n/a";
>>   }BOOST_CLOSURE_NAME(replace_empties);
>>   for_each( vec.begin(), vec.end(), replace_empties );
>
> Honestly, my goal was to show an example where Phoenix has limitations and
> Local could be considered an attractive alternative. Obviously my example
> failed to do that. I wanted to see how you can call member functions. I can
> see Phoenix has nice support for container-like operations. But how about
> changing the rules a bit, and calling an arbitrary member function?
>
>  for_each( vec.begin(), vec.end(),
>    if_(bind(&SuperLib::SuperString::IsVulgar, arg1)) [arg1 = "unknown" ]
>  );

I understand your goal and thank you. However, I honestly prefer to
keep the Local docs more "neutral". While the docs list all the
features of the different alternatives:
https://svn.boost.org/svn/boost/sandbox/local/libs/local/doc/html/boost_local/Alternatives.html#boost_local.Alternatives.local_functions

I wouldn't want to show examples that directly discourage one
alternative over another. I'd rather leave that judgment entirely up
to the library users (and the specific of their problem domain).

> vs.
>
>  BOOST_CLOSURE_PARAMS( SuperLib::SuperString & n ) {
>    if( n.isVulgar() ) n = "unknown";
>  }BOOST_CLOSURE_NAME(replace_vulgar);
>
>  for_each( vec.begin(), vec.end(), replace_vulgar );
>
> I realize that one can tweak examples to show whatever one wants. But
> member access does not appear too unusual. This really happened to me that
> I used a very complicated bind statement where I had to bind some variables
> and leave some free, pass some by reference, some by value. I thought "it
> was the right way because this is Boost way", until I realized no-one else
> in the team knows what that is suppose to mean.

Thanks again,
--Lorenzo