Re: [boost] [local] Any "active Boost library author" in favor of Boost.Local?

Subject: Re: [boost] [local] Any "active Boost library author" in favor of Boost.Local?
From: Vicente Botet (vicente.botet_at_[hidden])
Date: 2011-11-25 11:06:04

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-favor-of-Boost-Local-tp4106033p4107788.html
Sent from the Boost - Dev mailing list archive at Nabble.com.