Re: [boost] Graph stuff

From: jeremy siek (jsiek_at_[hidden])
Date: 2000-09-19 22:09:51

David Abrahams writes:
 > Well, actually I think PropertyMap is a fine name for a concept, and much
 > better than PropertyAccessor.
 > It does say exactly what it means.

Hmm, maybe PropertyMap is not as bad as I first thought.

 > >  > Too much, I still think. Something short and sweet would be better. If
 > you
 > >  > must have "accessor" in the name, then how about
 > >  > "edge_capacity::accessor(G)"?
 > >  > [I still don't like accessor <growl>]

Then this would be:

  edge_capacity::get_map(G)

And I suppose the type for the map would be:

  edge_property_map<Graph, edge_capacity>::type

or just:

  edge_map<Graph, edge_capacity>::type

 > >  > >  >   edge_capacity::get(G, e)
 > >  > >  >   edge_capacity::put(G, e, c)
 > >
 > > I can live with adding the above functionality to the adjacency_list
 > > class,
 > 
 > Is that really an adjacency_list function? I thought it was by definition a
 > member of the property class (aka "plugin").

The way in which internal properties are stored is entirely
graph-class dependant, so the functionality really does "belong" to
the graph class, regardless of how we define the interface.  If we go
with this interface, the edge_capacity::get() function would be a
templated function that just dispatches to the graph-class's function,
which probably counts as an argument against this interface. The
following is a similar interface that wouldn't need the extra
indirection:

  get(edge_capacity(), G, e);

 > > but I'd rather not add this interface to any graph concept.
 > > That should discourage its use in a graph algorithm.
 > 
 > Can we review the examples I've written about in light of whatever I've
 > battered <wink> you into accepting? Would you mind writing the examples out
 > so I can see how they look?

Sure, after your response to this one I'll write it up ;)

Cheers,

Jeremy