From: Dean Michael Berris (mikhailberis_at_[hidden])
Date: 2007-10-09 11:52:51
On 10/9/07, Marco <mrcekets_at_[hidden]> wrote:
> On Tue, 09 Oct 2007 16:45:29 +0200, Dean Michael Berris
> <mikhailberis_at_[hidden]> wrote:
> > (I'm also thinking of writing a bit more tests just to make sure it's
> > covered pretty well, and if I get the time write some in-line
> > documentation and perhaps split up the file into appropriate header
> > files. There's also a recommended Boost library directory structure,
> > and I'll try coming up with that as well.)
> > To the moderators on the list: I'm not sure how the subversion access
> > works, but will it be alright if this library continues to get
> > developed in the sandbox? Is there a specific process for that? And
> > would this be a candidate for a mini-review once the appropriate
> > documentation and "boostification" process gets done? Or would this
> > merit a full review just like the other libraries that try to become
> > part of the Boost C++ Library?
> Well obviously the proposed and uploaded implementation needs still a lot
> of testing.
Then we're in agreement. :) Let's get this into the Boost SVN sandbox
then go from there. Would love to get this version tracked and
developed collaboratively -- and preserve the history of the changes.
> About directory and namespace organization, this my point of view:
> in namespace boost::overloads::detail
> should be put all the helper functions and metafunctions
> in namespace boost::overloads
> the overload class and all the type information helper utilities
> ( has_signature<Sig, overload_type>, signature<N, overload_type>,
> extent<overload_type>, ...)
> then only the overload class is made available in the boost namespace
> through a using overloads::overload;
> with the source code belonging to namespace boost::overloads but not
> to namespace boost::overloads::detail
> with the source code belonging to namespace boost::overloads::detail only.
> These are just my speculations, I don't know if they fit with
> the boostification process, moreover we should take into account
> the possibility to include the new code straight into boost.function.
> But, IMO, this kind of decisions are up to boost moderators
> and the authors of boost.function.
About your proposed directory structure, I agree with this -- although
I would also like to see the different preprocessor macro's and helper
types divided up into separate files, even further.
There's also the libs/overloads directory which should contain the
examples, the tests, and the documentation. The Google doc can be
exported as HTML and maintained through Google docs still, but if we
follow the Boost convention (which is a good idea), we might want to
use quickbook for the documentation as well. It should be too hard to
get this done especially since we've already got some momentum going
as far as documentation is concerned.
For the inclusion in Boost.Function OTOH, I think that might be a
conversation with Doug -- but that doesn't remove the requirement for
the documentation nonetheless.
So until we haven't decided yet whether this is a separate utility or
a part of Boost.Function, I'll continue writing documentation. :)
Have a great day everyone!
-- Dean Michael C. Berris Software Engineer, Friendster, Inc. [http://cplusplus-soup.blogspot.com/] [mikhailberis_at_[hidden]] [+63 928 7291459] [+1 408 4049523]
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk