Re: [boost] Graph stuff

From: David Abrahams (abrahams_at_[hidden])
Date: 2000-09-19 13:11:00

----- Original Message -----
From: <jsiek_at_[hidden]>
To: <boost_at_[hidden]>
Sent: Tuesday, September 19, 2000 11:44 AM
Subject: [boost] Graph stuff

> Hi Dave,
>
> There's three things you point out:
>
> 1. replacing 'plugin' with 'property' and changing the order of
>   the tag and value type.
>   This seems reasonable to me.
>
> 2. Not using an extra typedef.
>   Of course we don't have control over how users will do this,
>   by I can certainly change the examples to use this style.
>
> 3. Using 'weight' instead of 'weight_tag'.
>   I'm hesitant because this will cause annoying name conflicts. I like
>   to use 'weight' for local variables. We've been using 'S' at
>   the end of the names of selectors in the interface, perhaps
>   'weightS'?

the 'S' rubs me the wrong way also; it goes against my personal rule "no
non-standard abbrvs" ;)
To follow boost conventions (?) it ought to be vec_s but I would prefer
select_vector or use_vector.
Isn't it really there to make up for lack of template template parameters?
If so, I would hesitate to use the same convention for weight, which will
never be a TTP.

Your local variable conflict shouldn't be an issue for users who abstain
from "using namespace boost" and "using boost::weight"... but the latter
construct probably ought to be given consideration.

If there is room to experiment, consider the following ideas:

// cumbersome, inflexible
properties< std::pair<int, weight_property>, std::pair<bool,
visited_property>,... >
property<int, weights>  // s just pluralizes
declare<int, weight_property> // cumbersome?
property<int, weight_tag> // back to using _tag. Maybe that's OK if you
don't use "plugin"
property<int, weight_> // too easy to lose the underscore
inject<int, weight_property> // obscure?
add<int, weight_property> // add is probably too general a name
property<int, edge_weight> // nobody puts weights on nodes anyway
   property<int, edge_color> // I realize there are some orthogonality
issues here...
   property<int, node_color> // ...but it may actually make the declaration
of the graph a lot clearer

Any of these things strike your fancy or set off a spark?

-Dave