finalizing the Iterator API

[Casper Boemann]

> > And as Boudewijn said up,down.left,right might be nice functions,
however
> > they don't make sense for a PathIterator. I have had this idea myself,
but
> > on reflection: when would they really be used.
>
> Edge detection, for instance.

good point, question is if we should make a special WalkerIterator for this
or just provide those functions in general.

> > Another Iterator I just tought of is an affine transformation, used to
> > scale, rotate and shear images.
>
> I have a hard time visualizing that, so I'd like to see it... Currently we
use
> affine transform code I ported from Qt, debugged by Bart, for all this,
but we
> really need bicubic interpolation scaling, as the current scaling is
really
> ugly.

Well it was only a thought but I was envisioned two iterators a normal and
the transformed. One would then walk the source and the other the
destination. If you always advance() both at the same time you would get a
mapping. All you would have to do is to sample around the source position
and store it at the destination position.

But I havn't thought this one through.

> > 2) it should allow any combination of int8, int12, int32, float,double,
> > bits
>
> Fortunately, the colour strategies already have the rudiments of a pixel
> description in the ChannelInfo structure. This needs to be extended and
> formalized -- here I really put my foot down. I don't want to have to
check
> the depth of the image every time I consult the ChannelInfo :-).


> > Anyway , the GOF (p 91 bottom paragraph)
>
> My offer to provide a copy to people not having that book still stands:
> however, not having the paper version handy, can you give the pattern you
> refer to?

Well it is not a pattern - that's just it. They didn't have a pattern to
refer to. They just talk about sending a base class into a function that
would then have to be cast to a more specialised class. I'm sure that if a
pattern was applicable they would at least refer to it.

It was a sidebar discussion under the abstract factory pattern: The factory
gives a baseclass pointer to the product, but what if you need to do
subclass specific handling.

> I feel convinced. Although -- see the pseudo-code I mailed in response to
> Cyrille's concerns. It seems a bit silly to have to manually ask the
colour
> strategy to parse the data into a pixel. Maybe we can provide a
PixelIterator
> that returns the parsed data, for those algorithms that need it that way,
and
> a PixelDataIterator that returns the pointer, for the algorithms that
leave
> all the real work to the colour strategy anyway.

yes - if you think of letting the iterator ask the colorstrategy for
parsing. No need to do that manually. However only if actually needed in
more than this single example - no need to bloat the interface