|
Boost : |
Subject: Re: [boost] [local] Any "active Boost library author" in favor of Boost.Local?
From: Simonson, Lucanus J (lucanus.j.simonson_at_[hidden])
Date: 2011-11-25 23:24:40
lcaminiti wrote:
>
> Hello all,
>
> I will be honest: The fact that some of the people arguing for not
> including Boost.Local are "active Boost library authors" (Thomas,
> Joel, and Hartmut) seems to make their opinion weight more than the
> opinion of others that have also submitted a review for the library.
>
> Two questions:
>
> 1) Should reviews from "active Boost library authors" carry more
> weight? (This is /not/ a rhetoric question.)
>
> 2) Is there any "active Boost library author" out there that is in
> favor of including Boost.Local? (If so, please say so by replying to
> this thread.)
Boost.Local was dead to me as soon as I found out that you had to bind local variables. The only advantage of the proposed library is that the body of the function goes next to where it is used rather than somewhere else. That's probably doable with either lambda+bind or phoenix. Personally, I don't value the ability to put the implementation of the function just before where it is passed into another function because it tears down the abstraction that a named function provides and reduces modularity and testability. I think a lambda is a good thing only if its entire body is a single statement that is very clear and short like {_1 < _2} where just in-lining it is as succinct as using a named function. If you are binding local variables to a function that you pass to another function you are doing something relatively clever. The behavior of that function should probably have a name so that your intention is self documenting, and you might also want to test it. I'd rather people's code be clear than clever. The macros don't help on that score. Having Boost.Local in addition all the other libraries which overlap it in scope in Boost would just make using boost more confusing. I agree completely with Hartmut.
Regards,
Luke
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk