Hello all, Boost.Closure (formerly, Boost.Local) needs to use some macros, types, etc that are currently marked private in Boost.ScopeExit: BOOST_SCOPE_EXIT_AUX_TAG boost::scope_exit::aux::undeclared ... So I will move these symbols from AUX/aux to another prefix/namespace. How shall the new prefix/namespace be named? These symbols should not go into the public API of ScopeExit because they should never be used by the end user. These symbols are only meant to be used by other parts of Boost so they should use some sort of "protected" prefix/namespace. For example, I could use "detail": "aux" for ScopeExit private API and "detail" for ScopeExit API that can be used within Boost but not by general users: BOOST_SCOPE_EXIT_DETAIL_TAG boost::scope_exit::detail::undeclared However, other Boost components already use "detail" for their private API (synonymous of "aux"). So, I could use "protected" instead: BOOST_SCOPE_EXIT_PROTECTED_TAG boost::scope_exit::protected_::undeclared What's the best convention to follow here? Thanks a lot. --Lorenzo
On 02.01.2012 10:25, Lorenzo Caminiti wrote:
Hello all,
Boost.Closure (formerly, Boost.Local) needs to use some macros, types, etc that are currently marked private in Boost.ScopeExit:
BOOST_SCOPE_EXIT_AUX_TAG boost::scope_exit::aux::undeclared ...
So I will move these symbols from AUX/aux to another prefix/namespace. How shall the new prefix/namespace be named?
These symbols should not go into the public API of ScopeExit because they should never be used by the end user. These symbols are only meant to be used by other parts of Boost so they should use some sort of "protected" prefix/namespace. For example, I could use "detail": "aux" for ScopeExit private API and "detail" for ScopeExit API that can be used within Boost but not by general users:
BOOST_SCOPE_EXIT_DETAIL_TAG boost::scope_exit::detail::undeclared
However, other Boost components already use "detail" for their private API (synonymous of "aux"). So, I could use "protected" instead:
BOOST_SCOPE_EXIT_PROTECTED_TAG boost::scope_exit::protected_::undeclared
What's the best convention to follow here?
Fix the design. If you as a Boost library developer "needs" this, then folks who /use/ Boost also need it. Another example of that: the use of preprocessor magic in Boost parameters lib. Microsoft once claimed that it was their intention that people should use undocumented stuff, then they'd document whatever became ad hoc standard (e.g. like lopen in early Windows). Boost should not be that kind, but alas, it already it is: I urge Boost developers to work *hard* (which is needed) to get the thing back on the Right Track(TM). Cheers & hth., - Alf
On 01/02/2012 10:25 AM, Lorenzo Caminiti wrote:
Hello all,
Boost.Closure (formerly, Boost.Local) needs to use some macros, types, etc that are currently marked private in Boost.ScopeExit:
Boost.Closure? I really don't like that name is at implies functional programming capabilities. Didn't you decide to name it Boost.LocalFunction instead?
Thomas Heller-7 wrote
On 01/02/2012 10:25 AM, Lorenzo Caminiti wrote:
Hello all,
Boost.Closure (formerly, Boost.Local) needs to use some macros, types, etc that are currently marked private in Boost.ScopeExit:
Boost.Closure?
My library implements closures as defined by http://en.wikipedia.org/wiki/Closure_(computer_science) (as discussed in this link for C++ and as with C++11 lambdas, C++ closures should not bind by reference when they are used outside their declaration scope): ``In computer science, a closure (also lexical closure, function closure, function value or functional value) is a function together with a referencing environment for the non-local variables of that function.[1] A closure allows a function to access variables outside its typical scope. Such a function is said to be "closed over" its free variables. The referencing environment binds the nonlocal names to the corresponding variables in scope at the time the closure is created, additionally extending their lifetime to at least as long as the lifetime of the closure itself. When the closure is entered at a later time, possibly from a different scope, the function is executed with its non-local variables referring to the ones captured by the closure.''
I really don't like that name is at implies functional programming capabilities.
For example, I programmed all the examples from the link above using my library. Is there an example of what you'd expect to do with a C++ closure that cannot instead be programmed with my library?
Didn't you decide to name it Boost.LocalFunction instead?
I'm equally happy with LocalFunciton or Closure. My review manager and one of the reviewers expressed a strong preference for Closure because a shorter name and more to the point of the library purpose so I'm adopting that name. --Lorenzo -- View this message in context: http://boost.2283326.n4.nabble.com/protected-APIs-tp4252824p4261817.html Sent from the Boost - Dev mailing list archive at Nabble.com.
lcaminiti wrote:
Thomas Heller-7 wrote
Boost.Closure? [snip] I really don't like that name is at implies functional programming capabilities. Didn't you decide to name it Boost.LocalFunction instead?
I'm equally happy with LocalFunciton or Closure. My review manager and one of the reviewers expressed a strong preference for Closure because a shorter name and more to the point of the library purpose so I'm adopting that name.
I have to admit that Boost.Local_Function sounds like a nice name to me, especially if the library implements "only" local functions. If local blocks and local exits would still be part of the library, I could understand why Boost.Closure might also be attractive, but I thought... But if you want to stress that the local functions created by the library can be returned easily from a function without taking special precautions (I don't know whether this is actually true), then Boost.Closure might not be a bad name after all. Regards, Thomas
On 01/02/2012 10:25 AM, Lorenzo Caminiti wrote:
Hello all,
Boost.Closure (formerly, Boost.Local) needs to use some macros, types, etc that are currently marked private in Boost.ScopeExit:
Boost.Closure? I really don't like that name is at implies functional programming capabilities. Didn't you decide to name it Boost.LocalFunction instead?
I second that concern. I wouldn't like for the local function library to claim the name 'closure'. This would be a) totally misleading and b) inhibits to give that name to a potential real closure library in the future. Regards Hartmut --------------- http://boost-spirit.com http://stellar.cct.lsu.edu
-----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Hartmut Kaiser Sent: Sunday, January 15, 2012 3:51 PM To: boost@lists.boost.org Subject: Re: [boost] "protected" APIs
On 01/02/2012 10:25 AM, Lorenzo Caminiti wrote:
Hello all,
Boost.Closure (formerly, Boost.Local) needs to use some macros, types, etc that are currently marked private in Boost.ScopeExit:
Boost.Closure? I really don't like that name is at implies functional programming capabilities. Didn't you decide to name it Boost.LocalFunction instead?
I second that concern. I wouldn't like for the local function library to claim the name 'closure'. This would be
a) totally misleading and b) inhibits to give that name to a potential real closure library in the future.
+1 - objection - Violent!!! ;-) to Boost.Closure - despite some rationale. Boost.LocalFunction is better. Paul --- Paul A. Bristow, Prizet Farmhouse, Kendal LA8 8AB UK +44 1539 561830 07714330204 pbristow@hetp.u-net.com
Hartmut Kaiser wrote:
On 01/02/2012 10:25 AM, Lorenzo Caminiti wrote:
Hello all,
Boost.Closure (formerly, Boost.Local) needs to use some macros, types, etc that are currently marked private in Boost.ScopeExit:
Boost.Closure? I really don't like that name is at implies functional programming capabilities. Didn't you decide to name it Boost.LocalFunction instead?
I second that concern. I wouldn't like for the local function library to claim the name 'closure'. This would be
a) totally misleading and b) inhibits to give that name to a potential real closure library in the future.
+1 Or more precisely, just ignoring mails questioning the name Boost.Closure is not good style. In a functional programming language, many things can be done with a closure (for example returning it from a function), and it is unclear to me, whether Boost.Local really is able to approximate this functionality in a sufficiently usable way. It might be true, but then please point me to the corresponding passage in the documentation. Regards, Thomas
on Mon Jan 16 2012, Thomas Klimpel <Thomas.Klimpel-AT-synopsys.com> wrote:
Hartmut Kaiser wrote:
On 01/02/2012 10:25 AM, Lorenzo Caminiti wrote:
Hello all,
Boost.Closure (formerly, Boost.Local) needs to use some macros, types,
etc that are currently marked private in Boost.ScopeExit:
Boost.Closure? I really don't like that name is at implies functional programming capabilities. Didn't you decide to name it Boost.LocalFunction instead?
I second that concern. I wouldn't like for the local function library to claim the name 'closure'. This would be
a) totally misleading and b) inhibits to give that name to a potential real closure library in the future.
+1
Or more precisely, just ignoring mails questioning the name Boost.Closure is not good style. In a functional programming language, many things can be done with a closure (for example returning it from a function), and it is unclear to me, whether Boost.Local really is able to approximate this functionality in a sufficiently usable way. It might be true, but then please point me to the corresponding passage in the documentation.
I think at this point the horse has left the barn. Whatever closure means to the FP community, C++11 has set a precedent by using the term to describe the objects created by lambda expressions. -- Dave Abrahams BoostPro Computing http://www.boostpro.com
participants (8)
-
Alf P. Steinbach -
Dave Abrahams -
Hartmut Kaiser -
lcaminiti -
Lorenzo Caminiti
-
Paul A. Bristow -
Thomas Heller -
Thomas Klimpel