Re: [boost] [intrusive] Interface for hooking into client code improvable?

From: Tobias Schwinger (tschwinger_at_[hidden])
Date: 2007-08-09 16:00:12

Olaf Krzikalla wrote:
> Hi Tobias,
> 
> as Ion already wrote the idea is interesting.
> However I have some remarks:
> 
> Tobias Schwinger wrote:
>> #include <boost/detail/lightweight_test.hpp> #include <map>
>>
>> class foo : public intrusive::slist_node_mgmt_data<foo> // Note: Base
>> class does not insert any names { int val_data; public:
>>
>> foo(int data) : val_data(data) { }
>>
>> int data() const { return this->val_data; }
>>
>> // Note: No "member hook" };
> IMHO 'ptr_next' is still injected in the name space of foo, since
> visiblitiy and accessibility are orthogonal concepts.
> 

Right, it was imprecise. Let's say:

     "No names of accessible members are injected ..."

Technically still sufficient to catch accidental name clashes, have them 
removed from syntax completion, etc.

>> // Management facility 
>> std::map<bar*,intrusive::slist_node_mgmt_data<bar> > bar_management;
>>
>> intrusive::slist_node_mgmt_data<bar>& get_mgmt(bar& that) { return
>> bar_management[& that]; }
> get_mgmt should be a functor. It's extremely difficult to pass
> contextual information to a free standing function. Your example shows
> that right off by simply operating on a global variable.

Yes, that idea was an "accidental bonbon" ;-).

The original intent was to provide a straightforward extension point to 
access member hooks, but of course it also allows non-intrusiveness 
(though stateless). I probably over-advertised it in the code comments.

As already admitted (in my reply to Ion), stateful function objects 
would be more flexible for the non-intrusive stuff.

Anyway,

> 
> The question is if we can or should (ab)use the traits class for this or
> if we introduce another template parameter like this:

here is where we reach my primary point: Improving the interface.

There are two much template parameters, already, and it seems that 
applying Boost.Parameter (to the template parameters of containers) 
would suit that library well:

It allows to split the container configuration at any grain desired and 
to add features in future versions without breaking the interface.

Positional template parameters whose meaning isn't immediately obvious 
(such as e.g. the non-type boolean ConstantTimeSize used by the 
Intrusive containers) tend make interfaces unintuitive, because readers 
of client code without in-depth knowledge of the library have to figure 
out what the arguments refer to. Named arguments OTOH lead to 
self-explanatory code.

I'd also like to see a 'T' parameter for straightforwardness

      template< class T, // [...]
      class container;

so one could just say

      container<T>

given 'T' has appropriate hooks installed. That "nested 'value_traits' 
business" feels pretty clumsy (much more than having the hooks inject 
public names) and it was my main motivation to look for something better.

Hope I haven't complained too much... The library is great; I have the 
impression that a lot of care went into the implementation -- its 
interface just /deserves/ some polishing ;-).

Regards,
Tobias