Re: [boost] Re: Iterator Adaptor Poll

From: Thomas Witt (witt_at_[hidden])
Date: 2002-07-28 13:15:19

Dave,

On Friday 26 July 2002 19:05, David Abrahams wrote:
> From: "Thomas Witt" <witt_at_[hidden]>
> I think the Policy Adaptor design pattern is valuable, at a higher level.
>
> > This idea is so usefull that the scope for
> > iterator_adaptor widened from adapting iterators to creating iterators,
>
> and
>
> If you're saying that iterator_adaptor oversteps its charter, I disagree.
> An iterator adaptor takes some core element and builds an iterator around
> it. If you can easily create an iterator adaptor, it's trivial (and
> logical) to go the next step and use the adaptor to build an iterator.

What I was referring to was that I think that the current design is at its 
limits if more complex policies are used. When trying to overcome the current 
problems I realized that the current design is really good for simple 
applications. To be more precise for those where the policies do not have to 
maintain state.

As soon as the policies have to maintain state the line between Policy Adaptor 
and Adapter/LeanIterator gets blurred. You have two options move the state in 
the adapted class or in the policies class. 
When doing the first it is more like Policy Adaptor but most of the time you 
will have to introduce two new classes. In the second case you only have one 
new class but its not really a policies class as default_iterator_policies 
is. I think that there is no clear distinction between both concepts it 
depends on the way you look at it.

> >
> > The policies class concept in the current implementation has a number of
> > problems. To me the worst are unsufficient encapsulation and distribution
>
> of
>
> > state.
>
> I agree that's a problem, but I don't think it's neccessarily a problem
> with the Policies concept.

I would not say so either. But I think that a policies concept that fixes 
these problems is closer to Adapter/LeanIterator than the current one.

>
> That's true. It relies on the convention that the iterator's users are only
> touching the interface of the Iterator concept, and not the other member
> functions (policies(), base()).

The short answer is actually a question: If convention is the right solution, 
why is "private" a keyword? Seriously I know there are scenarios where 
anything but convention would be an overkill. I just think this is not true 
for iterator_adaptor.

>
> > Today the state of
> > the iterator distributed between the iterator_adaptor and the policies.
>
> Yes, I really dislike that.
>
> > This
> > leads to no end of problems regarding comparison and const/non-const
> > interoperability.
>
> Really? No end? Please illustrate a few, since they are so plentiful ;-)

Ok maybe I was exaggerating a bit, but with the current design it is 
impossible to implement a cycle or joining iterator that has natural 
const/non-const interaction. A problem that can not be solved is a kind of a 
no end thing, isn't it?

> If Policies were required to be a metafunction class templated on the Base
> type, it might help to solve some of those problems. However,
> default_iterator_policies would have to be a metafunction as well, so that
> the Base type can be embedded in the Policies object.

Yes.

>
> I would like it very much if you would explore some of these designs with
> Jeremy. 

I would be happy to do so. 
Jeremy what do you think?

--Thomas

-- 
Dipl.-Ing. Thomas Witt
Institut fuer Verkehrswesen, Eisenbahnbau und -betrieb, Universitaet Hannover
voice: [phone] - 4273, fax: [phone]
http://www.ive.uni-hannover.de