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
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk