<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div>Hi Tobias,</div><div><br></div><div>very nice! I had a look at it and it works fine for me, also the CellImg seems to work as it did before.</div><div><br></div><div>I have one question about a protected constructor in RealPoint though:</div><div><br></div><div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; font: normal normal normal 11px/normal Monaco; color: rgb(59, 124, 199); "><span style="color: #000000"><span class="Apple-tab-span" style="white-space:pre"> </span></span>/**</div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; font: normal normal normal 11px/normal Monaco; color: rgb(59, 124, 199); "><span class="Apple-tab-span" style="white-space:pre"> </span> * Protected constructor that re<span style="color: #9094ad">-</span>uses the passed position array.</div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; font: normal normal normal 11px/normal Monaco; color: rgb(59, 124, 199); "><span class="Apple-tab-span" style="white-space:pre"> </span> *</div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; font: normal normal normal 11px/normal Monaco; color: rgb(59, 124, 199); "><span class="Apple-tab-span" style="white-space:pre"> </span> * <span style="color: #8ab1c9">@param</span> position</div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; font: normal normal normal 11px/normal Monaco; color: rgb(59, 124, 199); "><span class="Apple-tab-span" style="white-space:pre"> </span> * array used to store the position.</div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; font: normal normal normal 11px/normal Monaco; color: rgb(138, 177, 201); "><span style="color: #3b7cc7"><span class="Apple-tab-span" style="white-space:pre"> </span> * </span>@param<span style="color: #3b7cc7"> x</span></div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; font: normal normal normal 11px/normal Monaco; color: rgb(59, 124, 199); "><span class="Apple-tab-span" style="white-space:pre"> </span> * unused parameter that changes the method signature</div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; font: normal normal normal 11px/normal Monaco; color: rgb(59, 124, 199); "><span class="Apple-tab-span" style="white-space:pre"> </span> */</div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; font: normal normal normal 11px/normal Monaco; "><span class="Apple-tab-span" style="white-space:pre"> </span><span style="color: #9a1b66">protected</span> RealPoint( <span style="color: #9a1b66">final</span> <span style="color: #9a1b66">double</span>[] position, <span style="color: #9a1b66">final</span> Object x )</div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; font: normal normal normal 11px/normal Monaco; "><span class="Apple-tab-span" style="white-space:pre"> </span>{</div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; font: normal normal normal 11px/normal Monaco; "><span class="Apple-tab-span" style="white-space:pre"> </span><span style="color: #9a1b66">super</span>( position );</div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; font: normal normal normal 11px/normal Monaco; "><span class="Apple-tab-span" style="white-space:pre"> </span>}</div></div><div><br></div><div>Why is there the Object x in there?</div><div><br></div><div>Also I have a small question about the CellImg. The ListImgCells which holds all cells is typed to DefaultCell, and also always instantiates DefaultCells. Shouldn't that be the part where we are able to exchange them for other types of cells? So shouldn't it be typed to something like C extends AbstractCell<A> or so? Or is there another level where you want to introduce that?</div><div><br></div><div>Ciao ciao,</div><div>Steffi</div><div><br></div><div><div>On Mar 15, 2012, at 16:57 , Tobias Pietzsch wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div>Hi,<br><br>I've implemented more changes to the ImgLib2 abstract class hierarchy.<br>This time, I restructured the integer Positionables, Localizables, and<br>RandomAccesses.<br><br>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<br>want to need to fix that for the new abstract hierarchy later.<br>ListImg has also been changed a bit. And I made some cosmetic changes<br>here and there...<br><br>I think I broke nothing and I would merge this into master soon.<br><br>It would be totally awesome, if you could try your ImgLib2 stuff with<br>the branch "modified-abstract-hierarchy" and see if everything works okay. If you have time to comment on the changes I made - even better.<br><br>best regards,<br>Tobias<br><br>BTW: did you see the cool fractal example on<br><a href="http://fiji.sc/wiki/index.php/ImgLib2_Documentation#A_RealRandomAccess_to_Render_Mandelbrot_Fractals">http://fiji.sc/wiki/index.php/ImgLib2_Documentation#A_RealRandomAccess_to_Render_Mandelbrot_Fractals</a><br>?<br>:-)<br><br>On 03/13/2012 09:01 PM, Tobias Pietzsch wrote:<br><blockquote type="cite">Hi guys,<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">while I was writing ImgLib docs, I noticed that the current<br></blockquote><blockquote type="cite">abstract class hierarchy which leads to AbstractRandomAccess<T><br></blockquote><blockquote type="cite">is a little bit stupid (see attached imglib2-abstract-current.png)<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">There is no need for the abstract class hierarchy to pull the<br></blockquote><blockquote type="cite">Sampler<T> interface all the way through. The Sampler<T> is only<br></blockquote><blockquote type="cite">implemented in the concrete classes. There is really no need to have<br></blockquote><blockquote type="cite">the dependency on T in the abstract hierarchy. This prevents for<br></blockquote><blockquote type="cite">instance RealPoint to make use of the RealPositionable and<br></blockquote><blockquote type="cite">RealLocalizable implementations in AbstractRealRandomAccess<T>.<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">Therefore I propose to change the hierarchy as shown in the<br></blockquote><blockquote type="cite">second attached diagram, imglib2-abstract-proposed.png.<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">I implemented those changes for the "real" path, see branch<br></blockquote><blockquote type="cite">"modified-abstract-hierarchy". Note how nicely RealPoint fits<br></blockquote><blockquote type="cite">into the picture now :-)<br></blockquote><blockquote type="cite">Before I go ahead and do the same for the integer accessors, I wanted<br></blockquote><blockquote type="cite">to ask whether you agree that this is a good thing to do...<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">There is one more thing: The AbstractRealRandomAccess implemented<br></blockquote><blockquote type="cite">the complete RealPositionable interface, while AbstractRandomAccess<br></blockquote><blockquote type="cite">only implements part of Positionable - with the implemented part<br></blockquote><blockquote type="cite">based on the unimplemented methods. The idea was that if a derived<br></blockquote><blockquote type="cite">concrete accessor compiles you know you implemented what was necessary.<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">However, I found the approach of AbstractRealRandomAccess to implement<br></blockquote><blockquote type="cite">anything quite nice when using it. I would suggest doing the same for<br></blockquote><blockquote type="cite">integer. Then either<br></blockquote><blockquote type="cite">* you know what you are doing when overriding (parts of) the<br></blockquote><blockquote type="cite">Positionable implementation<br></blockquote><blockquote type="cite">* you leave it as is (e.g. Point)<br></blockquote><blockquote type="cite">* you derive from AbstractLocalizable and implement Positionable<br></blockquote><blockquote type="cite">completely on your own.<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">Thoughts?<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">best regards,<br></blockquote><blockquote type="cite">Tobias<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">_______________________________________________<br></blockquote><blockquote type="cite">ImageJ-devel mailing list<br></blockquote><blockquote type="cite">ImageJ-devel@imagej.net<br></blockquote><blockquote type="cite">http://imagej.net/mailman/listinfo/imagej-devel<br></blockquote><br></div></blockquote></div><br></body></html>