Re: [boost] Boost.Graph: named parameters/major interface change

From: Beman Dawes (bdawes_at_[hidden])
Date: 2001-04-16 15:29:38

At 12:12 PM 4/16/2001, Jeremy Siek wrote:

 >I've been looking into using the named parameters technique
 >for the algorithm interfaces in the Boost Graph Library.
 >For example, calling Dijkstra's algorithm would look like
 >this:
 >
 >dijkstra_shortest_paths(g, s, distance_map(d).predecessor_map(p));
 >
 >There are several advantages to this:
 >  - defaults no longer order-dependent
 >  - better readability
 >  - better defaults for "utility" properties. E.g., for color map
 >     the algorithm can by default use an internally allocated array.
 >
 >Ideally, we'd keep the old interface (and call it deprecated) and add
 >functions for the new named parameter interface. However, there are a few
 >places where the new functions would interfere with the old in terms of
 >function overloading.
 >
 >So there's two options:
 >
 >1) Ditch the old interface, replace it with the new.
 >
 >2) Keep the old interface, use different names for the new functions.

3) Deprecate the old interface, put the new interface in namespace 
boost::graph.

 >I'm in favor of option 1), but if there are strong feelings for
 >option 2) I can be swayed.

Thoughts,

*  If you do change the interface, consider putting it in boost::graph.

*  It seems like a lot of change if the advantage is only a minor interface 
improvement.  Only do it if you think it a really major improvement.

*  What impact would it have on the book?  You will be confusing people for 
years (and having to answer their questions) if the book ships describing 
an interface considerably different from the code.

--Beman