Re: [boost] Case study: Boost.Local versus Boost.Phoenix

Subject: Re: [boost] Case study: Boost.Local versus Boost.Phoenix
From: Gregory Crosswhite (gcross_at_[hidden])
Date: 2011-02-04 12:57:38

On 2/4/11 4:35 AM, Artyom wrote:
> I'm sorry is it only me or it would be much more readable
> and maintainable to write:

It isn't clear to me how writing all of that extra boilerplate makes 
things easier to understand.  BOOST_LOCAL_FUNCTION is not that hard to 
understand;  the name of the macro itself tells you very clearly what it 
is doing:  declaring a local function.  Furthermore, if anything I would 
argue that using structs to define functions makes things harder to 
understand by adding lots of extra noise that you have to go through 
before you figure out what the function actually does.

> I understand that Pheonix and boost::lambda are very useful
> in certain situations but am I only person who thinks
> that if you need some little bit more complicated lambda
> function you just create a small class with operator()
> which would be
>
> 1. Much More readable

Again, I have to strongly disagree with this.  If you have never seen 
BOOST_LOCAL_FUNCTION then it might take a small amount of time to get 
used to it, but after that it is incredibly clear what is going on at a 
glance, especially since it contains less boilerplate noise getting in 
the way.

> 2. Clear for source code maintainers who not familiar with some boost toolkits

True, but on the other hand this will always be true of any library that 
one chooses to use that is not standard C++.

> 3. Easier to debug and see compiler's error messages

The error messages usually aren't that bad for Boost.Local, and the 
syntax is simple enough that I found it relatively easy to figure out 
what went wrong compared to many other libraries.

> 4. Be friendlier to less experienced C++ programmers who would
>     have to maintain this horrible code?

I strongly object to you repeatedly calling my code horrible just 
because it does not follow your personal aesthetics.

> I do like and use boost::bind, boost::lambda and some other simple
> construction that can be written in a single like and what is
> most important improve programmer's productivity but I really
> fail to see it in this case.
>

Yes, but all of the arguments you have just made could be applied 
equally well against boost::bind and boost::lambda, so this isn't a 
matter of keeping things simple so much as a matter of personal 
preference.  In particular, I think that BOOST_LOCAL_FUNCTION is much 
clearer than boost::bind because there isn't actual line noise getting 
in the way of you seeing what is making the function call.

> - maintainer happy to be able to actually understand what
>    does the code do without reading Boost.Pheonix or Boost.Local
>    manuals for 5 hours.
>

If you saw BOOST_LOCAL_FUNCTION for the first time and had to look at 
the manual, there is no way that it would take you over even one hour to 
understand what it does unless you are very slow.  In fact, it would 
take much closer to 5 minutes than 5 hours.

In conclusion, while I agree that over-use of alien looking constructs 
can cause more trouble than it is worth I think that you are greatly 
exaggerating how hard it is to understand BOOST_LOCAL_FUNCTION.

Cheers,
Greg