-
Notifications
You must be signed in to change notification settings - Fork 142
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
HDF5.Dataset as an AbstractArray #930
Comments
How does the wrapper benefit over a direct subtyping of Logically, makes sense that it would be a subtype. I think the original rationale might have been to limit it's interface. |
We probably should implement AbstractDiskArray.jl. Perhaps stealing this, but querying more of the information rather than caching it like this implementation: https://github.com/AStupidBear/HDF5Utils.jl/blob/master/src/diskarrays.jl |
Do you think it would be best to make it a direct subtype:
vs. what HDF5Utils is doing where
and then defining
Which I think they are only doing since they don't own the |
Yes, we should look into making it a direct subtype. This is a 0.17 topic though. In contrast to the HDF5Utils.jl implementation, I think our implementation should be lazy. Another issue if we make it a direct subtype is that we will need to parameterize it. We will need to consider how to mitigate the compilation latency in this case. |
Please do subtype Myself and @meggart have wanted this to happen for quite a while, so if you have any problems feel free to ping. |
I'm going to let this slip to 0.18 since 0.17 already contains other breaking changes. |
Just linking my original implementation suggestion for a HDF5DiskArray: #615 In case it helps. |
Should
HDF5.Dataset
be anAbstractArray
?Alternatively, should we build a wrapper?
We almost have the entire AbstractArray interface implemented for
HDF5.Dataset
:https://docs.julialang.org/en/v1/manual/interfaces/#man-interface-array
The text was updated successfully, but these errors were encountered: