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

Tobias Pietzsch pietzsch at mpi-cbg.de
Tue Mar 13 15:01:40 CDT 2012


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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: imglib2-abstract-current.png
Type: image/png
Size: 148787 bytes
Desc: not available
URL: <http://imagej.net/pipermail/imagej-devel/attachments/20120313/05d42496/attachment-0002.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: imglib2-abstract-proposed.png
Type: image/png
Size: 92618 bytes
Desc: not available
URL: <http://imagej.net/pipermail/imagej-devel/attachments/20120313/05d42496/attachment-0003.png>


More information about the ImageJ-devel mailing list