RealRandomAccessible: extend RandomAccessible

[gselzer]

It seems to me like the RandomAccessible API makes perfect sense when applied to a RealRandomAccessible.

• In other words, a f:Rⁿ→T is also a f:Zⁿ→T.

For that reason, shouldn't a RealRandomAccessible also be a RandomAccessible?

[gselzer]

Could consider removing this method entirely, as the return type change already warrants a major version bump.

[tpietzsch]

I think we still want this method, but I would be happy with the return type change. We could make this a separate PR though, and also break more API while we are at it. For example, I think it would be better if the Views methods would all return interface types instead of concrete classes.

[gselzer]

Emphatic yes to returning interface types!

We could make this a separate PR though, and also break more API while we are at it.

Are you suggesting leaving the return type as is for this PR then?

[imagesc-bot]

This pull request has been mentioned on Image.sc Forum. There might be relevant details there:

https://forum.image.sc/t/fiji-friends-weekly-dev-update-thread/103718/99

[tpietzsch]

Ha! After thinking about it a bit, this makes sense, yes. A RealRandomAccessible can be accessed as a RandomAccessible.

It wouldn't extend to ReadRandomAccessibleRealInterval extends RandomAccessibleInterval though, because intervals also work in the "read-as" direction (Interval extends RealInterval).

I'm not sure about unintended side effects. For example Views.interval(RRA) would be possible and would "accidentally" also make the result Iterable. Do we want that?

I'm a bit reluctant. Could you give more context on why you need this? (I know it's somehow related to imglib2-meta, but I still haven't had time to dig into that.

[gselzer]

It wouldn't extend to ReadRandomAccessibleRealInterval extends RandomAccessibleInterval though, because intervals also work in the "read-as" direction (Interval extends RealInterval).

To be honest I hadn't fully thought that situation through, but yes, since Interval extends RealInterval I agree we cannot have RRARI extend RAI.

I'm not sure about unintended side effects. For example Views.interval(RRA) would be possible and would "accidentally" also make the result Iterable. Do we want that?

I guess I don't see the problem, at least as is... Views.interval suggests you can get a RAI from a RA. If you pass through a RRA acting as an RA, you'll get back an object that is no longer in real space, but that's within the guarantees of the method...

Where it gets trickier in that case is if we later want some Views.interval(RRA, RealInterval) -> RRARI. In that, case if you wrote

		BiConsumer<Localizable, DoubleType> c = (pos, out) -> out.setZero();
		RealRandomAccessible<DoubleType> rra = new FunctionRealRandomAccessible<>(2, c, () -> new DoubleType());
		RealRandomAccessibleRealInterval<DoubleType> rrari = Views.interval(rra, new FinalInterval(10, 10));

you'll get method clashing, which is unfortunate. Of course, we could just implement this interval solution on the fluent Views API side and avoid the problem...

I'm a bit reluctant. Could you give more context on why you need this? (I know it's somehow related to imglib2-meta, but I still haven't had time to dig into that.

Yeah, my motivations with this PR come from imglib2-meta.

One of the main goals of that project is to create a simple user-facing class Dataset, containing a delegate RandomAccessible along with a metadata container, to promote metadata-aware computation. Importantly, the Dataset is a RandomAccessible such that it can be passed as-is to all existing SciJava/ImgLib functionality.

Ideally, the RealDataset type, offering the same functionality a delegate RealRandomAccessible, would also be a Dataset, but for that to work its delegate would have to be a RandomAccessible.

Does that provide any helpful context?