On Mon, Nov 14, 2011 at 6:52 PM, Christian Holmquist <c.holmquist@gmail.com> 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