Open bogovicj opened 1 year ago
Currently, VolatileIntType extends AbstractVolatileNativeRealType, and is therefore a RealType. It is not currently an IntegerType, and probably should be.
VolatileIntType
AbstractVolatileNativeRealType
RealType
IntegerType
The same is true for other Volatile types:
VolatileByteType
VolatileUnsignedByteType
VolatileShortType
VolatileLongType
VolatileUnsignedLongType
VolatileARGBType
Adding AbstractVolatileNativeIntegerType and having the appropriate volatile types extend that would be a good step, and would be similar to the type hierarchy for non-volatile types (see AbstractIntegerType for example).
AbstractVolatileNativeIntegerType
AbstractIntegerType
This issue came up in n5-viewer https://github.com/saalfeldlab/n5-viewer/issues/34
one fix to that issue is with this PR in imglib2-ij https://github.com/imglib/imglib2-ij/pull/35
but this is the deeper issue. Some, maybe all of the changes in the above PR would not be necessary if the type hierarchy for volatile types were more fine-grained. e.g., if volatile types implemented IntegerType, the explicit checks using volatile types in the PR would not be necessary, because there is currently a check for IntegerType.
Currently,
VolatileIntTypeextendsAbstractVolatileNativeRealType, and is therefore aRealType. It is not currently anIntegerType, and probably should be.The same is true for other Volatile types:
VolatileByteTypeVolatileUnsignedByteTypeVolatileShortTypeVolatileLongTypeVolatileUnsignedLongTypeVolatileARGBTypeAdding
AbstractVolatileNativeIntegerTypeand having the appropriate volatile types extend that would be a good step, and would be similar to the type hierarchy for non-volatile types (seeAbstractIntegerTypefor example).Some specific motivation
This issue came up in n5-viewer https://github.com/saalfeldlab/n5-viewer/issues/34
one fix to that issue is with this PR in imglib2-ij https://github.com/imglib/imglib2-ij/pull/35
but this is the deeper issue. Some, maybe all of the changes in the above PR would not be necessary if the type hierarchy for volatile types were more fine-grained. e.g., if volatile types implemented
IntegerType, the explicit checks using volatile types in the PR would not be necessary, because there is currently a check for IntegerType.