Re: [boost] Re: Iterator Adaptor Poll

From: David Abrahams (dave_at_[hidden])
Date: 2002-07-26 12:05:49

From: "Thomas Witt" <witt_at_[hidden]>
> >
>
> I think that Jeremys analisys regarding the different purposes is
correct.
> IMHO the naming problem can only be solved by answering the question what
the
> purpose of an iterator_xxx is. As stated earlier I do not feel totally
happy
> with the current design.

Me neither.

> To me the biggest achievement of the current iterator_adaptor is the
> definition of a minimum set of operations needed to implement a full
fledged
> iterator interface.

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
> thats where the naming problems starts.

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.

> To me there are two ways to look at iterator_adaptor. The way currently
> represented in the documentation. It is called adaptor because it adapts
the
> behaviour of a given iterator

The thing being adapted does not have to be an iterator.

> using a policies class to describe the way the
> adaption should be preformed. The other way is to view the
iterator_adaptor
> template as an interface adapter modelling the adapter pattern in the GoF
> book. Where the policies really represent the concept of a
LeanIterator(or
> whatever you will call it). I think this view is more in line with the
> purpose of creating iterators. The user implements a LeanIterator and the
> library does the tedious work of implementing the full interface.
>
> 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.

> IIRC in the current design there is no way to prevent the user from
> manipulating the underlying iterator.

Right.

> As a result class invariants can not be
> guaranteed by the author of a specific iterator_adaptor.

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()).

> 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 ;-)

> I think that the adapter/LeanIterator view can be beneficial in
overcoming
> this problems. The adapter would only care about adapting the interface
> whereas the LeanIterator would care about behaviour and state.
Behavioural
> adaption would be as easy as it was before simply implement a new
> LeanIterator or derive from a supplied Adaptor<AdaptedIterator> that
> implements the LeanIterator interface.

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.

> I was going to propose a adapter/LeanIterator implementation somewhen in
the
> future. I have a working prototype that I use happily for roughly half a
year
> now.
>
> Thoughts?

I would like it very much if you would explore some of these designs with
Jeremy. I also think that some of Mat Marcus' ideas about using GenVoca as
a design pattern here has promise.

-Dave

-----------------------------------------------------------
           David Abrahams * Boost Consulting
dave_at_[hidden] * http://www.boost-consulting.com