Re: [boost] Rave for proposed Boost.Local (functions)

Subject: Re: [boost] Rave for proposed Boost.Local (functions)
From: Joel de Guzman (joel_at_[hidden])
Date: 2011-02-05 07:42:23

On 2/5/11 7:40 PM, Thomas Heller wrote:
> Mathias Gaunard<mathias.gaunard<at>  ens-lyon.org>  writes:
>> On 03/02/2011 16:45, Thomas Heller wrote:
>>
>>>>> Now, let's consider another case, I want to do a.foo(b.bar()) + c.baz,
>>>>> but with a, b, and c taken from the scope, and I don't want to have to
>>>>> specify the types of a, b, and c. I can't do that in Phoenix without
>>>>> defining the foo, bar and baz functions at namespace scope, since they
>>>>> must have a template operator(), which is only allowed at that level. I
>>>>> can, however, do that with no problem with Boost.Local.
>>>>
>>>> Well, you have seen nothing yet
>>>
>>>
> http://svn.boost.org/svn/boost/sandbox/SOC/2010/phoenix3/libs/phoenix/doc/html/
> phoenix/inside/extending_actors.html
>>> A boilerplate macro for that would be a very welcome contribution...
>>
>> All of this still needs to happen at namespace scope.
>
> Sure it would. The point of this exercise was to adapt some "old style" C++
> class to be used in a phoenix expression. Much in the fashion of
> BOOST_FUSION_ADAPT_STRUCT. Since you complained about using member functions
> in a phoenix expression is a pain ...
>
>> The problem with declaring those things at namespace scope is that they
>> necessarily become far away from the lambda function you want to write.
>
> Arguing like that disqualifies every library, since the defintion of the
> functions you want to use is _very_ far away... I don't see a point in that
> argument.

I think his argument is that with lambda expressions, the code is
at the call site. However, I'd also argue that for more complex
code spanning several statements, it is good practice to refactor
them into their own functions. Overly complex lambda functions are
a poor form.

Regards,
-- 
Joel de Guzman
http://www.boostpro.com
http://spirit.sf.net