[ImageJ-devel] proposed changes in the ImgLib2 abstract class hierarchy

[Tobias Pietzsch]

Hi,

I've implemented more changes to the ImgLib2 abstract class hierarchy.
This time, I restructured the integer Positionables, Localizables, and
RandomAccesses.

While I was at it, I merged a new version of CellImg (this is in 
preparation for CellImgs that swap Cells to disk) because I didn't
want to need to fix that for the new abstract hierarchy later.
ListImg has also been changed a bit. And I made some cosmetic changes
here and there...

I think I broke nothing and I would merge this into master soon.

It would be totally awesome, if you could try your ImgLib2 stuff with
the branch "modified-abstract-hierarchy" and see if everything works 
okay.  If you have time to comment on the changes I made - even better.

best regards,
Tobias

BTW: did you see the cool fractal example on
http://fiji.sc/wiki/index.php/ImgLib2_Documentation#A_RealRandomAccess_to_Render_Mandelbrot_Fractals
?
:-)

On 03/13/2012 09:01 PM, Tobias Pietzsch wrote:
> Hi guys,
>
> while I was writing ImgLib docs, I noticed that the current
> abstract class hierarchy which leads to AbstractRandomAccess<T>
> is a little bit stupid (see attached imglib2-abstract-current.png)
>
> There is no need for the abstract class hierarchy to pull the
> Sampler<T> interface all the way through. The Sampler<T> is only
> implemented in the concrete classes. There is really no need to have
> the dependency on T in the abstract hierarchy. This prevents for
> instance RealPoint to make use of the RealPositionable and
> RealLocalizable implementations in AbstractRealRandomAccess<T>.
>
> Therefore I propose to change the hierarchy as shown in the
> second attached diagram, imglib2-abstract-proposed.png.
>
> I implemented those changes for the "real" path, see branch
> "modified-abstract-hierarchy". Note how nicely RealPoint fits
> into the picture now :-)
> Before I go ahead and do the same for the integer accessors, I wanted
> to ask whether you agree that this is a good thing to do...
>
> There is one more thing: The AbstractRealRandomAccess implemented
> the complete RealPositionable interface, while AbstractRandomAccess
> only implements part of Positionable - with the implemented part
> based on the unimplemented methods. The idea was that if a derived
> concrete accessor compiles you know you implemented what was necessary.
>
> However, I found the approach of AbstractRealRandomAccess to implement
> anything quite nice when using it. I would suggest doing the same for
> integer. Then either
> * you know what you are doing when overriding (parts of) the
> Positionable implementation
> * you leave it as is (e.g. Point)
> * you derive from AbstractLocalizable and implement Positionable
> completely on your own.
>
> Thoughts?
>
> best regards,
> Tobias
>
>
>
> _______________________________________________
> ImageJ-devel mailing list
> ImageJ-devel at imagej.net
> http://imagej.net/mailman/listinfo/imagej-devel