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

From: Jonathan Turkanis (technews_at_[hidden])
Date: 2004-08-17 11:51:18

"Rob Stewart" <stewart_at_[hidden]> wrote in message
news:200408171530.i7HFUD728557_at_entwistle.systems.susq.com...
> From: "Jonathan Turkanis" <technews_at_[hidden]>
> >
> > "Thorsten Ottosen" <nesotto_at_[hidden]> wrote in message:

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

I guess it depends if you focus on how it looks when you're using it
or defining 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.

Yes. To me, calling the metafunction 'size' seems as misleading as
calling the member type 'size' instead of 'size_type'. This name is
better reserved for a function returning the actual size of a
collection.

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

I didn't make my point very well. The problem is not just that 'char'
is not a legal template name, but that when you shave of the _type
suffix to eliminate an apparent redundancy you might end up with
something with a slightly different intuitive meaning -- increasing
the chance that the name has already been used for something else and
is not available.

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

Yes, I know it's an existing convention, and I agree that it's good to
have some convention. The namespaces formed by adding 's' just sounds
funny to me. So I'm in favor of using 'ranges' for the namespace
associated with range, if such a namespace is needed, but if it's
debatable whether to use a namespace, I'm inclined to avoid the
awkwardness of the name.

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

Oddly, 'details' seems more natural to me than 'detail'. I guess it's
because 'detail' actually contains details, whereas 'tuples' doesn't
contain tuples (it contains 'tuple')

Jonathan