lcaminiti wrote
Hello all,
I will be honest: The fact that some of the people arguing for not including Boost.Local are "active Boost library authors" (Thomas, Joel, and Hartmut) seems to make their opinion weight more than the opinion of others that have also submitted a review for the library.
Two questions:
1) Should reviews from "active Boost library authors" carry more weight? (This is /not/ a rhetoric question.)
2) Is there any "active Boost library author" out there that is in favor of including Boost.Local? (If so, please say so by replying to this thread.)
Hi Lorenzo, I don't think that the fact to be a library author will/should carry more weight on the review result. What is important is the arguments. I've been reading all the threads related to this review, and I have changed by perception of Boost.Local some times. I think that the last mail of Joel that has convinced me. The example shows an alternative that is clear enough and that should avoid compile errors that are difficult to digest. Of course, this examples is using a non local function, and even if you can think that this is not a valid alternative, as the definition is no local, when we see the simplicity and the better performances we could expect I think that most of the people will prefer this alternative to the one proposed by Boost.Local. I think that most of us would admit that local functions are useful, but as discussed during the review, Boost.Local doesn't provides local functions. The missing features been: * implicit access to the accessible variables * access to the non public functions of the embedding class (in case of a local function of a member function). That means that the interface of the local function is equivalent to the one we could write directly using a global function (I think that just don't needing to repeat the types is not a major advantage). This doesn't means that the work you have done is lost, as if I understand correctly you need to be able to define local functions to manage with the constraints of your Boost.Contract library. So, I vote for no acceptance of Boost.Local. Sorry for the change, Vicente -- View this message in context: http://boost.2283326.n4.nabble.com/local-Any-active-Boost-library-author-in-... Sent from the Boost - Dev mailing list archive at Nabble.com.