Re: [boost] Graph stuff

From: David Abrahams (abrahams_at_[hidden])
Date: 2000-09-19 17:35:08

----- Original Message -----
From: "jeremy siek" <jsiek_at_[hidden]>
To: <boost_at_[hidden]>
Sent: Tuesday, September 19, 2000 5:46 PM
Subject: Re: [boost] Graph stuff

> David Abrahams writes:
>  > I don't see the problem here. You _are_ accessing the property... of
the
>  > entire graph! Then you can index the property with the particular edge
or
>  > vertex descriptor (you didn't throw out operator[] for
property-accessors,
>  > did you?) It makes complete sense to me (of course ;)), and I think
that
>  > once you've been exposed to the structure
(graph->property->property-value)
>  > the first time there are fewer constructs to remember.
>
> I'd still feel better if we could work the word 'accessor' into the
> interface.

Look, it's really not an accessor the way you've defined it... it's more of
a reference. In some sense, it's just like a descriptor - an abstract
identifier for the value(s) in question. The accessing all happens inside of
get()/put().

But anyway, I am fighting you because I don't want users to have to be
burdened with the (long) word "accessor". I know it means something to you,
but if we force users to come to grips with the concept, it's just more
mental overhead. I don't think there is commensurate benefit to having a
separate concept. I'm just trying to make this very powerful library easy to
learn and use.

>  > That's why I suggested using edge_property<Graph, edge_capacity>::type
>  > I still prefer edge_capacity::get(G) to get the edge_capacity of the
entire
>  > graph.
>
> How about replacing '::type' with '::accessor':

...here we go again... ;-)
For the same reasons mentioned above. Okay, I can understand why
edge_property<Graph, edge_capacity>::type might sound like the value_type of
the edge property. Maybe accessor is okay here, but I'd rather avoid it.
Even "descriptor" would be better. These really are the same concept, aren't
they?

>   edge_property<Graph, edge_capacity>::accessor
>
> And for the function, could you live with 'get_accessor'
>
>   edge_capacity::get_accessor(G)

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>]

>  >   edge_capacity::get(G, e)
>  >   edge_capacity::put(G, e, c)
>  >
>  > The more tokens you make people type/read the less usable your library
is,
>  > and the less maintainable your users' code is.
>
> The problem with what you've written above is that it is less generic.
> It is nice to be able to use both "interior" and "exterior" property
> accessors with a graph algorithm (the interface above only works for
> "interior" accessors). For example, you need vertex color to do
> breadth_first_search(), but you may not want to keep color around for
> the entire lifetime of the graph, a waste of space. So you allocate a
> vector, use it as a property accessor in BFS, then deallocate.

Fine, I have no problem with keeping the generic interface. And one should
use the generic interface for generic algorithms. But what about the poor
user who has built a specific graph and just wants to extract the least-cost
predecessor values from his vertices after running Djikstra?

Yo!
-Dave