Hi Tobias,<br><br>First of all, thanks very much for all the API improvements!<br><br>I just have one comment...<br><br><blockquote style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex" class="gmail_quote">
<blockquote style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex" class="gmail_quote">
Why is there the Object x in there?<br></blockquote><br>
If it wouldn't be there, then the compiler would be unable to<br>
distinguish whether you call<br>
protected Realpoint( final double[] position )<br>
or<br>
public RealPoint( final double... position )<br></blockquote>
<br>Sure, the dummy Object parameter differentiates the constructors. However, I do not believe such drastic measures are necessary. Why not do something like this instead:<br><br> <a href="https://gist.github.com/2144264">https://gist.github.com/2144264</a><br>
<br>I think it is easier to understand and accomplishes the same ends.<br><br>Regards,<br>Curtis<br><br><br><div class="gmail_quote">On Fri, Mar 16, 2012 at 10:18 AM, Tobias Pietzsch <span dir="ltr"><<a href="mailto:pietzsch@mpi-cbg.de" target="_blank">pietzsch@mpi-cbg.de</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hi Steffi,<br>
<br>
thanks a lot for having a look!<div><br>
<br>
On 03/16/2012 03:33 PM, Stephan Preibisch wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I have one question about a protected constructor in RealPoint though:<br>
<br>
/**<br>
* Protected constructor that re-uses the passed position array.<br>
*<br>
* @param position<br>
* array used to store the position.<br>
* @paramx<br>
* unused parameter that changes the method signature<br>
*/<br>
protected RealPoint( final double[] position, final Object x )<br>
{<br>
super( position );<br>
}<br>
<br>
Why is there the Object x in there?<br>
</blockquote>
<br></div>
If it wouldn't be there, then the compiler would be unable to<br>
distinguish whether you call<br>
protected Realpoint( final double[] position )<br>
or<br>
public RealPoint( final double... position )<div><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Also I have a small question about the CellImg. The ListImgCells which<br>
holds all cells is typed to DefaultCell, and also always instantiates<br>
DefaultCells. Shouldn't that be the part where we are able to exchange<br>
them for other types of cells? So shouldn't it be typed to something<br>
like C extends AbstractCell<A> or so? Or is there another level where<br>
you want to introduce that?<br>
</blockquote>
<br></div>
What we will exchange for the is the Cells< A, C > cells that is passed to the CellImg constructor. ListImgCells implements that interface such<br>
that every Cell is stored as an Object. If we would alter the Cell type<br>
here, than there would still be an Object required for cells that are<br>
currently not in memory. So the idea was to change the Cells< A, C ><br>
implementation from ListImgCells to something else, that does the caching and creates Cell objects when required.<br>
<br>
Currently, I'm using "new DefaultCell< A >(...)" to create cells to<br>
create all the cells in the ListImgCells constructor. When we type<br>
ListImgCells to C extends AbstractCell<A>, we would need to pass a<br>
type variable into the constructor and add a createNewCell() method<br>
to the AbstractCell. This could be done, but let's wait until we<br>
actually need it.<br>
<br>
The current idea is to exchange the Cells< A, C > implementation.<br>
<br>
best regards,<br>
Tobias<div><div><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Ciao ciao,<br>
Steffi<br>
<br>
On Mar 15, 2012, at 16:57 , Tobias Pietzsch wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
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<br>
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<br>
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" target="_blank">http://fiji.sc/wiki/index.php/<u></u>ImgLib2_Documentation#A_<u></u>RealRandomAccess_to_Render_<u></u>Mandelbrot_Fractals</a><br>
?<br>
:-)<br>
<br>
On 03/13/2012 09:01 PM, Tobias Pietzsch wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hi guys,<br>
<br>
while I was writing ImgLib docs, I noticed that the current<br>
abstract class hierarchy which leads to AbstractRandomAccess<T><br>
is a little bit stupid (see attached imglib2-abstract-current.png)<br>
<br>
There is no need for the abstract class hierarchy to pull the<br>
Sampler<T> interface all the way through. The Sampler<T> is only<br>
implemented in the concrete classes. There is really no need to have<br>
the dependency on T in the abstract hierarchy. This prevents for<br>
instance RealPoint to make use of the RealPositionable and<br>
RealLocalizable implementations in AbstractRealRandomAccess<T>.<br>
<br>
Therefore I propose to change the hierarchy as shown in the<br>
second attached diagram, imglib2-abstract-proposed.png.<br>
<br>
I implemented those changes for the "real" path, see branch<br>
"modified-abstract-hierarchy". Note how nicely RealPoint fits<br>
into the picture now :-)<br>
Before I go ahead and do the same for the integer accessors, I wanted<br>
to ask whether you agree that this is a good thing to do...<br>
<br>
There is one more thing: The AbstractRealRandomAccess implemented<br>
the complete RealPositionable interface, while AbstractRandomAccess<br>
only implements part of Positionable - with the implemented part<br>
based on the unimplemented methods. The idea was that if a derived<br>
concrete accessor compiles you know you implemented what was necessary.<br>
<br>
However, I found the approach of AbstractRealRandomAccess to implement<br>
anything quite nice when using it. I would suggest doing the same for<br>
integer. Then either<br>
* you know what you are doing when overriding (parts of) the<br>
Positionable implementation<br>
* you leave it as is (e.g. Point)<br>
* you derive from AbstractLocalizable and implement Positionable<br>
completely on your own.<br>
<br>
Thoughts?<br>
<br>
best regards,<br>
Tobias<br>
<br>
<br>
<br>
______________________________<u></u>_________________<br>
ImageJ-devel mailing list<br>
<a href="mailto:ImageJ-devel@imagej.net" target="_blank">ImageJ-devel@imagej.net</a><br>
<a href="http://imagej.net/mailman/listinfo/imagej-devel" target="_blank">http://imagej.net/mailman/<u></u>listinfo/imagej-devel</a><br>
</blockquote>
<br>
</blockquote>
<br>
</blockquote>
<br>
</div></div></blockquote></div><br>