Hi Marco! On 10/9/07, Marco <mrcekets@gmail.com> wrote:
On Tue, 09 Oct 2007 16:45:29 +0200, Dean Michael Berris <mikhailberis@gmail.com> 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;
directories/files: (1) boost/overload/overload.hpp with the source code belonging to namespace boost::overloads but not to namespace boost::overloads::detail (2) boost/overload/detail/overload.hpp 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@gmail.com] [+63 928 7291459] [+1 408 4049523]