RE: [boost] Re: libs/iterator/doc/iterator_facade.html typo?

From: David Bergman (davidb_at_[hidden])
Date: 2004-02-12 12:11:04

David Abrahams wrote: 

> Angus Leeming <angus.leeming_at_[hidden]> writes:
> 
> > David Abrahams wrote:
> >>> In the section "Template Arguments for iterator_facade" is the 
> >>> subsection "CategoryOrTraversal". I suspect that should be 
> >>> "CategoryOfTraversal" (s/Or/Of/).
> >>>
> >>> The iterator_adapter docs spell it "CategoryOrTraversal" too.
> >> 
> >> No, the spelling is as intended.

The naming of the implementation, and the (informal, so far?) proposal by
you, Siek and Witt (sp?), is a bit misleading.

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.

2. Why is one concept group (i.e., one part of the dichotomy) called
"category" and the other "traversal." Potential confusion ahead... I propose
"access" and "traversal," 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 ;-) Furthermore,
connected to (1), category is often used to denote a group of concepts, so I
understand Angus' confusion.

3. In the traversal group/category of concepts, they should either *all*
include the lexeme "traversal" or *none*. 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...

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?

Comment (4) above is a bit whimsical, admittedly, and I do understand the
benefit of sticking to Iterator in the discussions, to easier combine with
existing notions and concepts in STL.

/David