Re: [boost] Boost.Local Review (Nov 10, 2011 to Nov 19, 2011)

Subject: Re: [boost] Boost.Local Review (Nov 10, 2011 to Nov 19, 2011)
From: Lorenzo Caminiti (lorcaminiti_at_[hidden])
Date: 2011-11-15 13:15:53

On Mon, Nov 14, 2011 at 7:35 PM, Lorenzo Caminiti <lorcaminiti_at_[hidden]> wrote:
> On Mon, Nov 14, 2011 at 7:31 PM, Lorenzo Caminiti <lorcaminiti_at_[hidden]> wrote:
>> On Mon, Nov 14, 2011 at 6:52 PM, Christian Holmquist
>> <c.holmquist_at_[hidden]> wrote:
>>>> > Boost.Local is the only library this far in Boost that I have to silently
>>>> > pronounce in my head before I realize that it's not Boost.Locale.
>>
>> Key points to keep in mind when searching for the name are:
>> 1) I'm not a native English speaker so distrust my opinion ;)
>> 2) In CS local functions are know as either local functions (C++ uses
>> similar terms like local classes (not nested classes), local
>
> I forgot a reference for the local function name. Here it is (it's N2511):
> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2511.html
>
>> variables, etc) or nested functions (used by wiki, GCC, etc):
>>    http://en.wikipedia.org/wiki/Nested_function#An_example
>>    http://gcc.gnu.org/onlinedocs/gcc/Nested-Functions.html
>> 3) Should this library be merged with Boost.ScopeExit? If so, this
>> library name might or not need to overlap with existing ScopeExit
>> macros.*
>>
>> Alternatives I could think of are:
>> a) Boost.Local: BOOST_LOCAL_FUNCTION (current), BOOST_LOCAL_EXIT,
>> BOOST_LOCAL_BLOCK
>> b1) Boost.Nested: BOOST_NESTED_FUNCTION (as named by GCC),
>> BOOST_NESTED_EXIT (does this make sense?), BOOST_NESTED_BLOCK
>> b2) Boost.Nested: BOOST_NESTED_FUNCTION, BOOST_NESTED_SCOPE_EXIT (does
>> this make more sense? is it too long?), BOOST_NESTED_BLOCK
>> c) Boost.Scoped: BOOST_SCOPED_FUNCTION (does this make sense?),
>> BOOST_SCOPED_EXIT (too similar to existing BOOT_SCOPE_EXIT?),
>> BOOST_SCOPED_BLOCK
>> d) Boost.Scope: BOOST_SCOPE_FUNCTION (does this make sense?),
>> BOOST_SCOPE_EXIT (same as existing name but different API),
>> BOOST_SCOPE_BLOCK

Andrzej proposed to also consider CLOSURE instead of FUNCTION name:
http://en.wikipedia.org/wiki/Closure_%28computer_science%29

If we use CLOSURE instead of FUNCTION, the alternatives become:

a) Boost.Local: BOOST_LOCAL_CLOSURE[_END], BOOST_LOCAL_EXIT[_END],
BOOST_LOCAL_BLOCK[_END]

b1) Boost.Nested: BOOST_NESTED_CLOSURE[_END], BOOST_NESTED_EXIT[_END],
BOOST_NESTED_BLOCK[_END]
b2) Boost.Nested: BOOST_NESTED_CLOSURE[_END],
BOOST_NESTED_SCOPE_EXIT[_END], BOOST_NESTED_BLOCK[_END]

c) Boost.Scoped: BOOST_SCOPED_CLOSURE[_END], BOOST_SCOPED_EXIT[_END],
BOOST_SCOPED_BLOCK[_END]

d) Boost.Scope: BOOST_SCOPE_CLOSURE[_END], BOOST_SCOPE_EXIT[_END],
BOOST_SCOPE_BLOCK[_END]

Do you have any preference?
    FUNCTION or CLOSURE?
    And also a), b1), b2), c) or d)?
    (Or something else...)

>> I'd say either a) or b2) because they give the most descriptive names
>> to the function, exit, and block macros. All, which one you do you
>> prefer?
>>
>> (*) Here's what I propose in a footnote of the Tutorial section:
>> [17] Rationale. This library could be merged together with
>> Boost.ScopeExit into a new library named Boost.Scope (from the meaning
>> of the word "scope" in computer programming). This would be justified
>> by the fact that BOOST_LOCAL_EXIT simply extends the functionality
>> already provided by BOOST_SCOPE_EXIT. The headers will be
>> "boost/scope/function.hpp", "boost/scope/block.hpp", and
>> "boost/scope/exit.hpp" (for backward compatibility with
>> Boost.ScopeExit, the header "boost/scope_exit.hpp" could also be kept
>> and it would be equivalent to including "boost/scope/exit.hpp").
>> However, the new BOOST_SCOPE_EXIT macro will not be backward
>> compatible with the current Boost.ScopeExit macro because it will
>> require to prefix the bound variable with bind or const bind (in order
>> to differentiate from constant and non-constant binding and to prevent
>> the bound tokens from ever starting with a non-alphanumeric symbol
>> like &). Local blocks would be named "scope blocks" and they would be
>> provided by the BOOST_SCOPE_BLOCK... macros (the "scope block" name
>> seems reasonably expressive). However, local functions would have to
>> be named "scope functions" and they would be provided by the
>> BOOST_SCOPE_FUNCTION... macros. This name might not be expressive
>> enough because local functions are not known under the name of "scope
>> functions" -- they are indeed known by either the name of "local
>> functions" or by the name of "nested functions" (GCC compiler
>> extension).

Thanks.
--Lorenzo