Re: [boost] function review

From: Douglas Gregor (gregod_at_[hidden])
Date: 2001-06-14 07:10:04

On Thursday 14 June 2001 07:13, you wrote:
> The following comments are personal opinions and should not be confused
> with my role as review manager.
>
> I like function and I think it should be accepted into boost.
>
> The following points are just a few that I don't think have been brought up
> yet:
>
> Docs:
> In the section on member function pointers (both index.htm and faq.htm) it
> may be worth pointing out that std::bind_1st(std::mem_fun_ref(_m_f)) can be
> used for member functions taking one argument (see also
> <boost/functional.hpp>).

OK.

> Headers:
> There seem to be a lot of headers under boost/, would it be an idea to move
> everything except function.hpp to boost/function/  ?

I'll throw out another suggestion: we could move all of the Boost.Function 
headers into boost/callback/, because function is only the first step in a 
full-fledges Boost callback library (will include at least signals & slots, 
but there might be useful intermediate steps as well).

> Implementation:
> Is there any reason why you have duplicated is_void in function_base.hpp
> rather than use the type traits version?  If it's because of the size of
> <boost/type_traits/arithmetic_traits.hpp>, then I'll split is_void off into
> a separate sub-header (I should do this anyway, but you might persuade me
> to get a move on :-)  )

I never thought to look in arithmetic_traits.hpp for an is_void :)

> I wonder whether the "detail" namespace should be replaced with
> "function_detail" or "function::detail" whichever you prefer - I worry
> about namespace clashes if everyone uses "detail".  Having said that if you
> don't think that it's a problem then leave it for now.

Function has a lot of helper classes, so it probably should have its own 
detail namespace.

> Like almost everyone else I'm not keen on boost::nil, personally I would
> just leave it out, but if you really want it, then renaming to something
> else seems to be in order (to avoid the mac problem).

I really like 'nil' (because I dislike OO-style interfaces for simple 
components), but I'll go with the general consensus.

> - John Maddock
> http://ourworld.compuserve.com/homepages/john_maddock/

        Doug