Re: [boost] [local] Review

Subject: Re: [boost] [local] Review
From: Joel de Guzman (joel_at_[hidden])
Date: 2011-11-18 23:23:31

On 11/19/2011 11:44 AM, Lorenzo Caminiti wrote:
> On Fri, Nov 18, 2011 at 10:19 PM, Joel de Guzman
> <joel_at_[hidden]> wrote:
>> On 11/19/2011 6:44 AM, Lorenzo Caminiti wrote:
>>>> As boost is trying to not only push the boundaries of C++ it should also try
>>>>> to set examples of best C++ practice. I would not consider Macro calls to
>>>>> interface with a library not good practice.
>>> I understand. I disagree but I understand your point. I disagree
>>> because the use of macros in this context saves the user from writing
>>> verbose boiler-plate code.
>>>
>>> IMO, it is similar to Boost.ScopeExit: Instead of providing the
>>> SCOPE_EXIT macros we could have said that the user writes the code to
>>> bind the variables deducing their types and it programs the local
>>> class with the exit code in the desstructor all of that by hand.
>>> However, using macros saves the user to write all of that and as I
>>> user I personally appreciate that. It is true that there is a trade
>>> off between the readability cost of using macros and the benefit of
>>> not having to write boiler-plate code. I find that trade off
>>> acceptable for libraries like Boost.SopeExit or even ForEach and (of
>>> course ;) ) also for my library so I don't have to write the
>>> boiler-plate code for the binding and the casting to pass the local
>>> class as a template parameter.
>>
>> I share Thomas' sentiment. But IMO, it's really not about using macros.
>> it's about the syntax. Boost.Foreach looks exactly like a for loop.
>> The proposed boost locals syntax is arcane. IMO, bottomline: it's
>> about the design of the DSEL regardless how it is implemented. And,
>> the syntax proposed is, well, utterly ugly. Anything more complex than
>> foreach, done using the PP will be a mess. An ugly syntax can be acceptable
> 
> That is fine but the definition of "ugly" is subjective so IMO it
> should be left up to the reviewers (and Thomas' point is clear, the
> syntax is ugly for him as one of the reviewers).
> 
>> IFF there is no other way to do it. In this case (locals), there are
>> better ways of doing the same thing.
> 
> But there is no other way to do locals allowing to use statement
> syntax for the function definition.

Why can't we C++ programmers just accept the fact that we don't
have *true* local functions like those in Pascal and Modula?

Challenge: try to port one moderately sized Pascal code (I
suggest a recursive descent calculator parser) using your
proposed library. I know the result will be utterly ugly and
unreadable compared to the real thing, but let the readers be
the judge.

I can write the same using non-local functions and/or offline
function objects using only straight C++. The result will be
very readable. Not as elegant as the one using Modula's local
functions, but certainly better than using your proposed locals
library. That is what I mean by "better ways of doing the same
thing".

Again, I share Thomas' sentiment. It's not worth the additional
complexity and arcane syntax. There are two scenarios here:
1) simple local functions --for those, you don't want the
complexity of using a macro DSEL, just use plain functions and
function objects. 2) Moderate to complex programs --for those,
the macro syntax will get in the way of clarity of code -- for
those, just use plain functions and function objects.

And I am not even mentioning c++ lambda. You can nitpick all
you want, but it's still nitpicking. Nitpicks are not valid
rationale for justifying a library for boost.

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