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
> > > must have "accessor" in the name, then how about
> > > "edge_capacity::accessor(G)"?
> > > [I still don't like accessor <growl>]
Then this would be:
And I suppose the type for the map would be:
> > > > > 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
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 ;)
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk