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

From: David Bergman (davidb_at_[hidden])
Date: 2004-02-12 16:57:49

David (Abrahams),

First of all, I am excited that your proposal has been formally excepted
into the TR, since the dichotomy of yours is the way to go. The reason for
me to stay at the naming of things is to make you understand that there is a
slight possibility of even quite skilled individuals being led astray by the
terminology; as to perhaps clarify certain notions in forthcoming revisions.

Ok, you saw that there are two orthogonal issued pertaining to the iterator
classifications, i.e., traversal and access.

In your proposal, dated 1/19, under the section Design, you write:

        "The iterator requirements are to be separated into two groups. One
set of concepts handles the syntax and semantics of value access ... The
other set of concepts handles traversal"

There you enumerate the various concepts in each "group" (you also use the
word "set" later.)

>From this I thought it would be safe to use the term "group of concepts" or
"concept group" for "set of concepts" or "requirement groups."

So, the traversal concepts is one group and the access concepts another.

You have to map these two orthogonal dimensions into the old, simple
hierarchy. You choose to make the traversal concept group pivotal, e.g., you
"do not provide tags for the purposes of dispatching based on the access
concepts." That is fine.

Since the old treatment of iterators dealt with only one dimension, they
used the word "category." No need to be more specific "back then..."

It is a bit confusing if we, in this new two-dimensional iterative world,
use "category" *both* for the combined (intersected) concepts, being
analogous to the old concepts, *and* for one of the dimensions. In our case,
Traversal.

We have to make the meta programming facilities, such as the tags used, be
backward-compatible, with that I agree. So, we have to keep the "category
tag" and "iterator category" and map them to something sensible.

We just have to live with the categories, as realized by category tags,
dealing *both* with unique combinations of the two orthogonal issues
(backward compatibility etc.) *and* with only one of the issues, Traversal,
I assume.

Could one not make that clear, such as:

        "category tags can dispatch based on both traversal capability and
the combined capabilities of traversal and access"

I understand, and always understood, your proposal, which is very welcome,
but I do also understand if others might find the mentioning of "category" a
bit misleading, since we have the old, combined world, and the new dichotomy
to deal with. 
And... one does, unfortunately, use the word "category" in generic
programming for both a single concept and a family of related concepts,
often including refinement hierarchies :-| I prefer the less charged word
"set of concepts" that you used.

Thanks,

David