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:35:58

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

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

--Lorenzo