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

From: David Abrahams (dave_at_[hidden])
Date: 2004-08-18 07:30:03

"Jonathan Turkanis" <technews_at_[hidden]> writes:

> "Rob Stewart" <stewart_at_[hidden]> wrote...
>> 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.

I'm ambivalent.  value_type<Foo>::type looks silly, but people are
familiar with value_type as value_type and reference as reference.
There's gonna be reference<Foo>::type.

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

Right.

>> > 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')

And in the near future we may end up with totally unrelated names;
the contents of boost::fusion will supplant those of boost::tuples.

-- 
Dave Abrahams
Boost Consulting
http://www.boost-consulting.com