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-14 19:31:22

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.
>> >
>> > Since the two libraries for a while was active on the mailing list at the
>> > same time, it did cause me some confusion in the beginning.
>> > I'm very easily confused, however, so quite possible I'm the only one
>> > seeing this as a problem :)
>> >
>> > That said, it's absolutely no big deal, but I think it would be better if
>> > the names were not so closely named..
>> >
>>
>> Do you have any preferred alternative name to Local?  (or, I guess,
>> Locale...but almost surely too late to change that!)
>>
>>
> Boost.LocalFunction?

Well... no because Boost.Local is not just about local functions. I
also has local blocks and local exits so LocalFunction will not cover
the entire domain of Boost.Local and it will make the names of the
macros for local exits BOOST_LOCAL_FUNCTION_EXIT and local blocks
BOOST_LOCAL_FUNCTION_BLOCK misleading.

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
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

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