-
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
move attributes to new file, add docs #943
Conversation
Looks pretty good to me. Should the Dataset, File, and Group related methods end up in attributes? Should we parcel those out to files as well? Is there a bigger plan for a file tree? |
I'm not sure what you mean: can you give an example?
I'd like to split up the functionality so it is easier to navigate and understand the API. At the moment, it is not even clear what the user-facing APIs are, let alone where they're defined. I originally tried to split them out with #833, but that was too ambitious, so I decided a piecemeal approach might be easier to manage. This also makes it a bit easier to refactor and identify smaller changes. For example, after looking at this, there are a couple of things we might to consider to refactor (but I'll leave for separate PRs):
|
While I kind of agree, I'm also not sure why this is a problem. Is there any ambiguity that this causes at the moment? |
I think we should target this for 0.17. |
2.45 | ||
``` | ||
""" | ||
function read_attribute(parent::Union{File,Group,Dataset,Datatype}, name::AbstractString) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
How do we decide that read_attribute
belongs in attributes.jl and not objects.jl?
If this were an OOP language, this method would belong to the types of parent
.
Do we move all the attribute related methods into their own file mainly because these are leaves in the HDF5 tree?
Basically, I'm just trying to figure out the organization principle so we can be consistent going forward.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'll admit that there aren't any clear rules, but there are a couple of reasons to keep it here:
- they all use the attribute (
h5a_XXX
) C API functions - attributes are an "extra" thing stuck on top of HDF5 (i.e. you can define groups, datasets etc without referring to attributes at all)
- in this particular case, it is a method that applies to multiple objects (so if you were to put it with those, it would need to be defined multiple times)
(anyway, that was why i wanted to leave it to a new PR) |
## Convenience interface | ||
|
||
```@docs | ||
h5readattr | ||
h5writeattr | ||
``` |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't know what to call these functions (honestly, these might be another good candidate for deprecation)
Is it possible to have an attribute or dataset with the same name in a group? One technical advantage I see to your approach is that we would likely improve type stability overall by doing this. I do think |
Overall, I would be in favor of merging this sooner rather than later. |
Yes:
|
I'm convinced. The interface needs to be deprecated. |
Let's set a deadline of May 4th to merge this. I just want to give it more time because of the US holiday so everyone can see it. |
end | ||
end | ||
Base.cconvert(::Type{API.hid_t}, attr::Attribute) = attr | ||
Base.unsafe_convert(::Type{API.hid_t}, attr::Attribute) = attr.id |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
👍
Looks great to me, I'm also in strong approval of all the suggestions in
On the last bullet, I agree. It's not very clear why dataset act like attributes and it's certainly far more descriptive to make users call attributes on the dataset if that's what they want to work with. |
After looking at this a bit more, I thing one other change that may make sense is that |
This appears to be what h5py does: https://docs.h5py.org/en/stable/quick.html#attributes |
Do you mean |
Maybe we should have a Meanwhile, perhaps we should parameterize attribute by its Julia type and have it work like a |
I would also be interested in comparing to the Zarr.jl as well. |
As part of my intermittent effort to clean up the code, this moves all the attributes-related stuff to a new file, and adds some docs.