Re: [boost] [local] Review

Subject: Re: [boost] [local] Review
From: Thomas Heller (thom.heller_at_[hidden])
Date: 2011-11-20 20:36:15

Please let me clarify my vote again. Please also note, that the quality 
of the implementation and documentation is out of doubt.

I vote to not include Boost.Local into Boost for the following reason.
I obviously can not appreciate the value of local functions in C++. C++, 
IMHO, has better ways to structure code (namespaces and classes).
Therefor, Boost.Local is not an alternative to C++-Lambdas, Boost.Bind, 
Boost.Lambda or Boost.Phoenix, but to regular C++ functions

That being said, I don't see Boost.Local as a complement to the other 
already existing functional programming style libraries. I see it as a 
complement to regular functions. It is true that this implementation of 
local functions leads to function objects that can be used as callbacks 
where something callable is expected. However, that does not mean that 
they are higher order functions, which in turn means that they are not 
easily composable (that means, there is no way to compose two local 
functions to form another local function other than calling the macros 
again). Which has another side effect that they are completely 
incompatible with the existing solutions (ok, you can bind them again).
Also, i think the verbosity of the macros defeat their initial purpose 
of "avoiding cluttering other parts of the program with functions, 
variables, etc unrelated to those parts". Additionally I can not see how 
local functions hide any information at all, the information is still 
visible (although hidden behind two enclosing, quite verbose, macro calls).

I admit the fact, that we as C++ Programmers need Macros to avoid 
repeating ourselves (aka boilerplate code). A lot of libraries do 
exactly this, and it is considered good practice. My main point of 
critique was that the Boost.Local seem to implement a quite complex 
logic and, basically, their own language. I would not consider the 
preprocessor the proper place to implement a DSEL.

Again, Lorenzo's effort and ingenuity of creating this very library is 
out of question, I solely believe that it is not the proper solution to 
this problem.