From: David Abrahams (dave_at_[hidden])
Date: 2004-02-12 15:13:13
"David Bergman" <davidb_at_[hidden]> writes:
>> > The naming of the implementation, and the (informal, so far?)
>> > proposal by you, Siek and Witt (sp?), is a bit misleading.
BTW, the proposal is not informal. It was accepted into the TR.
>> Well, it seems as though you were misled somewhere along the way.
> Ok, let us see.
>> > A few comments/suggestions:
>> > 1. A group of concepts should be called either "group" or "category"
>> > (I think you stick to the former most, of not all, of the time)
>> > consistently in both proposal and implementation.
>> I have no idea what you're referring to. Maybe you should
>> specifically point to text you think should be changed, and why.
> I think you have an idea of what I am talking: the proper name to
> use for the concept groups.
No, I really don't. What is a "concept group"?
> You want to stick to "group" because the Standard uses that name.
I do? Where does the Standard use that name?
> Fine, makes sense. I have seen "category" being used for that
I'm still lost. Why don't you just take my suggestion instead of
insisting that I already know what you're talking about? Quote some
text from the paper, say "I think it should say ________", and then
say why you think so. It's not so hard.
>> > 2. Why is one concept group (i.e., one part of the
>> dichotomy) called
>> > "category"
>> Because that's what the existing standard calls it.
> The existing standard does not even split the Iterator group into two
> dimensions, so how can they call that not-yet-invented dimension anything?
The standard defines "iterator categories".
> They use "category tags" for tags to groups, and subgroups, of concepts.
> I.e., their use has nothing to do with the "access" dimension.
It incorporates the "access" dimension.
> Additionally, does not "category tags" for tagging groups of
> concepts somehow imply that the word "category" for concept groups
> is not all that far far-fetched.
I still don't know what "concept group" means.
>> > and the other "traversal."
>> Because that's what it describes.
>> > Potential confusion ahead... I propose "access" and "traversal,"
Those are already the terms we use.
>> Existing category tags do not describe just access. They
>> describe a combination of access and traversal, as you can
>> see by reading
> Category tags is one thing, the "access" dimension another. This is where
> the possible confusion might arise:
> a. groups of concepts - called "groups"
> b. the tag used to label a group, or subgroup, of concepts - called
> "category tag"
The term "category tag" refers to tags such as
std::random_access_iterator_tag corresponding to old-style iterator
categories, such as "random access iterator".
The term "traversal tag" refers to tags such as
boost::random_access_traversal_tag corresponding to iterator traversal
concepts, such as "random access traversal iterator".
> c. the access group of concepts pertaining to iterators - called "category"?
No, I'm telling you that we're not using the word "category" to
describe access concepts. "Category" was established by the existing
standard, and it mashes together traversal and access.
>> > since I see no more of a "categorically" intrinsic property in one
>> > group than the other, i.e., labeling the access dimension as
>> > categorical is a bit unfair to the poor traversal dimension ;-)
>> It would be, but we're not doing that.
> So, what are you calling that other, orthogonal group, if not "category"?
>> > Furthermore, connected to (1), category is often used to denote a
>> > group of concepts, so I understand Angus' confusion.
>> I don't know what you're talking about again.
> You do not know that the word "category" is often used to denote a group of
> concepts in generic programming? As in "category tags."
?? Each standard iterator category denotes a single concept, as I
understand it. The concepts happen to form a refinement hierarchy,
but I don't see what that has to do with it.
>> > 3. In the traversal group/category of concepts, they should either
>> > *all* include the lexeme "traversal" or *none*.
>> Probably a good idea. We made that change to the tags, but
>> not to the concept names.
>> > In fact, I propose to completely skip the "traversal" in
>> the concept
>> > names. The only potential conceptual hurdle is the "access" in
>> > "random_access" (or RandomAccessIterator) that can be confused with
>> > the access-related group of concepts...
>> Bad idea, IMO. incrementable_tag, for example, shouldn't be
>> reserved by an iterators library; it could apply to lots of things.
> I agree with that cross-group applicability of the tag, but what has that
> insight to do with skipping "traversal" in the concept names?
The words single-pass or bidirectional will have different meanings
in different contexts.
>> > 4. The access group of iterator concepts: what is so "iterative"
>> > about them? I.e., are they not general proxy concepts,
>> with potential
>> > applications in smart pointers and other proxy situations?
>> ...and your point is...?
> Exactly the point you made in your last comment, namely, that "it could
> apply to lots of things."
>> They were designed so that they could be used independently
>> from traversal.
> That was the point I was making...
I don't think the requirements on a a "readable" file should
neccessarily be the same as those on a "readable" iterator.
-- Dave Abrahams Boost Consulting 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