Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Which parts of this project should go to imglib2 core? #1

Open
hanslovsky opened this issue Apr 3, 2017 · 2 comments
Open

Which parts of this project should go to imglib2 core? #1

hanslovsky opened this issue Apr 3, 2017 · 2 comments

Comments

@hanslovsky
Copy link
Member

Many of the classes and interfaces in this project could be added to imglib2 core. Essentially, all packages that are not named unsafe plus most of net.imglib2.img.unsafe. The classes in net.imglib2.img.unsafe should be renamed from Unsafe<...> to LongAccess<...>.

This would leave only a small portion of the classes in imglib2-unsafe but these classes would all make use of sun.misc.Unsafe.

License headers and JavaDoc will need to be adjusted before moving any of the classes to imglib2 core.

Opinions? @axtimwalde @tpietzsch

@axtimwalde
Copy link
Member

axtimwalde commented Apr 3, 2017

@hanslovsky and @tpietzsch and @StephanPreibisch I would prefer to add the long access methods to https://github.com/imglib/imglib2/tree/master/src/main/java/net/imglib2/img/basictypeaccess
and default them to their int counterparts. There is no guarantee for int access either that a particular int is available. Opinions?

@hanslovsky
Copy link
Member Author

hanslovsky commented Apr 3, 2017

I think that adding these methods and defaulting to their int counterpart is reasonable. I agree that it is the caller's responsibility to provide appropriate accesses. If necessary, callers can add their own validity checks for their access/images.

In addition, I think that what is currently called UnsafeImg and related classes should be added to imglib2 core as LongAccessImg (or similar name).

Updated:
As a consequence of unifying basictypeaccess and LongAccess, would that mean that NativeType will be changed to be accessible through long index? As with the access, the long access methods could default to their respective int counterparts.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants