Re: [boost] Re: Iterator Adaptor Poll

From: Thomas Witt (witt_at_[hidden])
Date: 2002-07-26 11:04:46

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Dave, Jeremy,

On Friday 26 July 2002 17:07, Jeremy Siek wrote:
> On Fri, 26 Jul 2002, David Abrahams wrote:
> dave>
> dave> As a replacement for the existing iterator_adaptor? Do you really
> dave> want to drop "adaptor" from the name? It's not a "Policy builder"
> dave> pattern, after all...
>
> Well, iterator_adaptor really has two purposes: adapting and creating from
> scratch. It seems to me that the name "builder" encompasses both of these
> purposes better than "adaptor".
>

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.

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

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 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. IIRC in the current design there is no way to prevent the user from 
manipulating the underlying iterator. As a result class invariants can not be 
guaranteed by the author of a specific iterator_adaptor. Today the state of 
the iterator distributed between the iterator_adaptor and the policies. This 
leads to no end of problems regarding comparison and const/non-const 
interoperability.

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.

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?

- --Thomas

- -- 
Dipl.-Ing. Thomas Witt
Institut fuer Verkehrswesen, Eisenbahnbau und -betrieb, Universitaet Hannover
voice: [phone] - 4273, fax: [phone]
http://www.ive.uni-hannover.de
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE9QXMk0ds/gS3XsBoRAsVOAJ9MvAU/UdbQOAeJs+RRLeN/CalLAACfQteU
SdexPBkdK7f1BvTs4cSdG8U=
=R6Wk
-----END PGP SIGNATURE-----