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
>> > 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
> 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
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk