finalizing the Iterator API

[Casper Boemann]

> > >From you experience with the other iterators, are there anything you
would
> >
> > like to change navigationvise - now that we have the chance..
> >
> > GOF uses done() to check for reaching the end. You use another iterator
to
> > compare with. GOF also lists your method as an alternative (also lists
an
> > alternative of advance() returning a status) so I'm not saying there is
> > anything wrong. It's just a matter of taste, and now that you have had
some
> > experience with use, you might have som wishes.
>
> Unfortunatelly my experience has been "polluted" by the STL, which use
begin()
> and end(), and Qt et kdelibs use also begin() / end(), so I think we
should
> keep them.

Ok fine, I kind of prefer those as well for the very same reason. Just
wanted to be sure, that you or anyone else wouldn't argue for changes. If we
are going to do a rewrite we might as well harvest any experience. It's
settled then.

> As for the ".h", here is my opinion :
> * I don't see the difference between KisPixelIterator and
> KisPixelRectIterator.

Well KisPixelIterator is just a super class (oh I forgot that in the class
definition didn't I)
Other subclasses besides Rect could be Path or Line, or Extent
They only visits some pixels. The superclass doesn't really do anything - I
think it should be abstract.
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.
Another Iterator I just tought of is an afine transformation, used to scale,
rotate and shear images.

> * the reason why I made two iterrators (one for the line and one for the
> pixel) was that it might be usefull to skip a line or to go back to the
> beginning
> * I think that iterrator should not return a pointer, but they should be
able
> to give the value of a pixel and to modify it so that why I started to add
> the two following operators :
> operator QUANTUM ();
> operator=(QUANTUM v);
> * I do really think that we need an operator that return a class
representing
> a pixel, a class which look like this :
> class PixelRepresentation {
> public:
> operator[](Q_INT32 a);
> operator=(PixelRepresention a);
> }
> which may be use like this :
> PixelRepresentation a;
> PixelRepresentation b;
> a[RED] = 0.2*b[BLUE] + 0.6*c[RED] + 0.2*c[GREEN]
> a[BLUE] = 0.4*b[BLUE] + 0.3*c[RED] + 0.3*c[GREEN]
> a[GREEN]= 0.6*b[BLUE] + 0.1*c[RED] + 0.3*c[GREEN]
> b = a;

I think Boudewijn said it best. Also it doesn't allow int and float mixed og
even double and float. or 8 and 16 bit int.

Also it means that every pixel needs to be copied several times.

The prime requirements when defining our pixel representation are:
1) it should store only the actual channel data. No configuration data -
since that would cost too much memory when storing several millions of
pixels.
2) it should allow any combination of int8, int12, int32, float,double, bits
3) copyable without knowing interpretation
4) it should either be
   a) truly universal, but that requires configuration info clashing with
requirement 1
   b) dynamic down-castable to specific imagetypes but that also clashes
with 1
   c) static down-castable which is what my proposal does.

Anyway , the GOF (p 91 bottom paragraph) discusses a similar problem, and
doesn't refer to a usable pattern. It actually alludes that there are none
except the same solution I propose. Note our problem is even worse because
we have even more requirements.

We could change my proposal to a pointer to an entirely empty class, but
that is only name calling, and we would still have to static downcast to
specific subclasses in the colorstrategies.

The problem with an empty class is that calling sizeof() would be wrong (can
sizeof be overloaded to give a compile error?). Also an empty class that
actually contains something seems wrong to me conceptually. For example you
cannot have an array of these empty classes. The byte array seems more
correct.

The benefit of an empty class is that the iterators return a pointer to a
Pixel class, which may seem more descriptive to the programmer.

Anyway I'm willing to use an empty class, if the rest of you insists. I do
however think it gives more complicated and errorprone code, but it is
definitely doable.

> as for accessing to the tilenumber by (col,row), i don't understand why it
is
> usefull ?

yes it is because of the dynamic layersize I'm working on. It may be
possible to encode the row,col as a single number but that would just be yet
another calculation to do for no real benefit. Row and col of a tile remain
the same when the size of the device changes. tilenum does not as it depends
on the number of columns (which obviously will  no longer be constant)

best regards
Casper Boemann