Re: [boost] Re: [boost.range] post-review

From: Rob Stewart (stewart_at_[hidden])
Date: 2004-08-17 10:30:13

From: "Jonathan Turkanis" <technews_at_[hidden]>
> 
> "Thorsten Ottosen" <nesotto_at_[hidden]> wrote in message:
> > "David Abrahams" <dave_at_[hidden]> wrote:
> 
> > |   boost::iterators::value<I>::type
> > |   boost::iterators::reference<I>::type
> > |
> > |   boost::ranges::value<R>::type
> > |
> > | and so forth?
> >
> > good idea to rename value_type<I>::type value<T>::type :-)
> > I guess we should do that with
> >
> > range::size<R>::type
> > range::difference<R>::type
> 
> I don't like dropping the '_type' here -- One of the main advantages
> of a naming convention is that you can figure out what the name should
> be without consulting the docs. Consider a nearly identical situation

The duplication, "..._type<...>::type," seems silly, though,
doesn't it?  Having said that, the "_type" can simply be
construed as saying that the type is a type generator, and the
"::type" as the generated type.  What's more, while the entire
expression is meaningful, the class template isn't well named.

That is, boost::iterators::value<I> is less helpful than
boost::iterators::value_type<I>.  Then, knowing that such a type
is a type generator, you apply it by accessing the "type" nested
type.

So, I'm now thinking it isn't so bad to duplicate "type" in the
expression, though it still would be nice to eliminate it.

> in my iostreams library (to be reviwed later this month). Instead of
> 
>     typename Source::char_type
> 
> I use
> 
>    boost::io::char_type<Source>::type
> 
> If we were to drop the '_type' we would have boost::io::char, which is
> illegal. Same for int_type. Of course, the convention could be to keep
> '_type' if necessary, or to use a trailing underscore, but I'd rather

A convention that you add a trailing underscore to keywords
should be easy enough to administer and remember.  However, the
type name isn't very meaningful outside the full expression.

> > Namespaces on concepts seems to be an issue.
> 
> Namespaces on a concept don't bother me at all. For each of a
> concept's associated types -- when possible -- there should be an
> official metafunction defining the association. This metafunction has
> to be in *some* namespace or other.

I agree.

> I think range_xxx and ranges::xxx are about equally good. I don't
> really like the convention of forming namespace names by adding 's' -- 

I think that's a really good convention.  For example,
boost::tuples is the namespace for the code from which one can
create tuple types.  That is, various specializations of
boost::tuple.

However, this convention is the opposite of the detail namespace
which I think should be named "details" instead since it holds
more than one implementation detail.  (No, I don't expect to see
that change, but it would be more sensible to me.)

-- 
Rob Stewart                           stewart_at_[hidden]
Software Engineer                     http://www.sig.com
Susquehanna International Group, LLP  using std::disclaimer;