[boost] [bimap] Too much multi-index in interface?

From: Daryle Walker (darylew_at_[hidden])
Date: 2007-07-17 14:24:46

I was checking out the BiMap docs at 
<http://cablemodem.fibertel.com.ar/mcape/oss/projects/mc_projects/boost_projects/boost_bimap.html>, 
especially the Doxygen information about the classes.  I was thinking 
that BiMap looked complicated, and something about that bothered me. 
When I read BiMap's history, especially its relation to MultiIndex, I 
figured out what could be wrong:

        BiMap is too much an exemplar of MultiIndex.

The interface of BiMap has a lot of features that showcase the fact that 
it was built using MultiIndex.  The tagging interface for alternative 
names for "left" and "right" and the ability to specify the indexing 
philosophy (set, map, hash, list, vector) for the sides and the 
container as a whole (a.k.a. "set type of relation") seem like big cases 
of You Aren't Going To Need It.  The STL maps don't give this kind of 
customization, maybe because it isn't necessary.  If you don't like the 
names "left" and "right," just use new names in whatever class you'll be 
wrapping the bimap around.  Specifying indexing strategies just limits 
how the bimap can be internally constructed, possibly limiting efficiency.

There is also a lot of exposed template meta-programming (something 
complained about in a recent SlashDot thread).  The main template 
interface even uses it (to let the user exclude one or both comparison 
types while still specifying an allocator)!  What's wrong with:

//==================================================================
enum link_modes { one_and_one, one_and_many, many_and_one,
                   many_and_many };

template < typename LeftT, typename RightT, link_modes LinkMode,
            typename CompareL = ::std::less<LeftT>,
            typename CompareR = ::std::less<RightT>,
            class Allocator = ::std::allocator<
             ::std::pair<LeftT, RightT> > >
class bimap;
//==================================================================

(There's no tagging or index-specifying because YAGTNI.  There's also no 
"politically correct" substitute for std::pair.)  You don't just use the 
interface as if it was straight-forward, it actually is 
straight-forward.  That means that there's less to go wrong.  Sometimes 
as a developer, you have to Just Say No to 15 billion points of 
customization, even if the internal pieces allow them.  Design an 
optimal interface for BiMap first, then see how a MultiIndex can help in 
the implementation, even if the multi-index ends up being hidden (or not 
used at all!); don't design with the priorities reversed.  (It's a 
little late for BiMap, but maybe whoever does the MRU [most recently 
used] idea should take this into account.)

-- 
Daryle Walker
Mac, Internet, and Video Game Junkie
darylew AT hotmail DOT com