[ImageJ-devel] [fiji-devel] Re: equal iteration order

Tobias Pietzsch pietzsch at mpi-cbg.de
Wed Mar 21 12:27:52 CDT 2012


Hi,

I cleaned up the "equal iteration order" mechanism.


In the end, I did not use an interface "FlatIterationOrder".
The reason was that this interface can not be propagated through wrapper
classes (like ImgPlus). Even though ImgPlus.equalIterationOrder( f )
propagates to its wrapped img like

   return img.equalIterationOrder( f );

this breaks when you try to compare the iteration orders of two ImgPlus
for instance. The first solution to this would be to

   return f.equalIterationOrder( img );

and assume f does the same and you propagate alternately down to the
un-wrapped IterableIntervals. However, you would have to be super
careful not to provoke infinite loops in this way.



So instead of this, I introduced a new method in the
IterableRealInterval interface:

   public Object iterationOrder()

It is supposed to return an Object that represents the particular
iteration order. Comparison of iteration orders is via Object.equals().
That is, if you want to find whether IterableIntervals A and B have
equal iteration order, you ask whether

   A.iterationOrder().equals(B.iterationOrder()).

equalIterationOrder() is deprecated. I still changed it everywhere to
have it still work but some day we should remove it to keep the
IterableRealInterval interface as small as possible.

So, FlatIterationOrder is a class now. If you support flat iteration
order, then your iterationOrder() method should return a
FlatIterationOrder instance constructed with your Interval.


best regards,
Tobias

On 03/13/2012 02:40 PM, Albert Cardona wrote:
> El 13 de març de 2012 9:39, Albert Cardona<sapristi at gmail.com>  ha escrit:
>> ImgLib2'ers:
>>
>> Instead of this:
>>
>>   ( IterableRandomAccessibleInterval.class.isInstance( f ) ||
>> ArrayImg.class.isInstance( f ) || ListImg.class.isInstance( f ) ) )
>>
>> Why not create the empty interface EqualIterationOrder and make all
>> the above classes implement it? This way code will be future-proof,
>> and flexible to user-defined new Img classes.
>>
>> Albert
>
>
> Too early in the morning. I meant a new interface "FlatIterationOrder".
>
> Albert
>
>




More information about the ImageJ-devel mailing list