Re: [boost] [functors] proposal

Subject: Re: [boost] [functors] proposal
From: Vicente J. Botet Escriba (vicente.botet_at_[hidden])
Date: 2013-10-24 13:40:20

Le 23/10/13 14:02, Piotr Wygocki a écrit :
> On 23 October 2013 13:21, Vicente J. Botet Escriba <vicente.botet_at_[hidden]
>> wrote:
>> Le 23/10/13 13:10, Piotr Wygocki a écrit :
>>
>>   Than you for your feedback!
>>>
>>>
>>>   Are you aware of Boost.Phoenix ( or its predecessor Boost.Lambda ) ? Also
>>>> some of the functors appear to duplicate functors in the C++ standard
>>>> library in functional.
>>>>
>>> 1) This is good point, this functors are for this kind of people who like
>>> lambdas.
>>>
>>>    Many of proposed functors are equivalent to very simple lambdas.
>>>    For example:
>>>       ArrayToFunction can be replaced in most cases replaced with
>>>
>>>      auto arrayToFunction = [&](int i){ return v[i];};
>>>
>>> or
>>>
>>>     auto arrayToFunction = phoenix::ref(v)[_1];
>>>
>>>     In this case my proposal is to standarize this kind of popular usage:
>>>     auto arrayToFunction = make_ArrayToFunctor(v);
>>>
>> Popularity is subjective.
>
> Sure. I chose functors which are popular in MY opinion.
> I think you agree that "Less" is popular.
>
>
>>   2) There is another use case for people who like passing functors and need
>>> default arguments.
>>>
>>>    For example my SkipFunctor does exactly the same job as
>>> phoenix::nothing.
>>>    For example my RetrunFalseFunctor does exactly the same job as
>>> phoenix::val(true).
>>>
>>>    Look at this use case:
>>>
>>>    template <typename SomeAction =  SkipFunctor, typename StopCondidtion =
>>> ReturnFalseFunctor>
>>>    struct Algorithm {
>>>
>>>    };
>>>
>>>    AFAIK it cannot be replaced with phoenix construction because we do not
>>> have the type of the nothing functor.
>>>    Particularly, note that decltype(phoenix::nothing) is not going to work.
>>>
>>>    This is tiny difference but this play a big role in a code I write.
>>>
>>>   What about adding phoenix::true_/phoenix::false_**?
> I don't get it. Could you be more specific?
>
> I'd like to reestablish my use case. My previous post was messy (sorry!).
> We've got a class which can be modified by some functors.
> This functors have default values:
>
>    template <typename SomeAction =  SkipFunctor, typename StopCondidtion
> =ReturnFalseFunctor>
>    struct Algorithm {
>        Algorithm(SomeAction action = SomeAction(), StopCondidtion =
> StopCondition());
>
>    };
>
> Could you solve this using constructions from phoenix?
> The second question is of course: is this a good design?
>
>
I was just suggesting that if these functors are missing in 
Boost.Phoenix, just make a Feature request, propose a patch with the 
code, the documentation and test and I'm sure the author will accept it.

I was also suggesting that the name could be true_ and false_ for 
instead of  ReturnTrueFunctor and ReturnFalseFunctor

Best,
Vicente