Re: [boost] [functors] proposal

Subject: Re: [boost] [functors] proposal
From: Piotr Wygocki (vwygos_at_[hidden])
Date: 2013-10-24 14:16:21

Hi Vincente, thank you for your response.

IMO these structs do not belong to phoenix, because they behave in a
different way (see me struct Algorithm example).
In fact in many use cases they are redundant with phoenix structs.
Also I see no big interest in these functionalities.
I conclude these scenarios are not so common as I thought and I should keep
my toys for myself :)

Kind Regards,

Piotr

On 24 October 2013 19:40, Vicente J. Botet Escriba <vicente.botet_at_[hidden]
> wrote:

> 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
>
>
> ______________________________**_________________
> Unsubscribe & other changes: http://lists.boost.org/**
> mailman/listinfo.cgi/boost<http://lists.boost.org/mailman/listinfo.cgi/boost>
>