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

make all objects ref objects, add attribute JSON iterator #32

Merged
merged 7 commits into from
Nov 17, 2019

Conversation

Vindaar
Copy link
Owner

@Vindaar Vindaar commented Nov 17, 2019

From one of the commit messages:

This change was long overdue.

HDF5 objects track all sorts of internal state to keep track of the
objects within the HDF5 C libray. This means for a large number of
operations, which don't change the given object from a user
perspective a `var H5*` object still had to be available, which often
meant having to declare e.g. a group or dataset as `var` although
apparently nothing that changes the objet would take place,
e.g. reading a simple dataset.

With every object being a `ref object` we kind of circumvent this,
because the immutability of a `ref object` refers to the reference
itself and not the object the reference points to.

Also from a more abstract point of view this makes a whole lot more
sense. These objects are not objects stored in a H5 file, but are
just *references* to objects in a file. Thinking about immutability of
such objects when the HDF5 C library does all sorts of crazy stuff in
the backend is almost ridiculous.

Also the tables, which store the different subgroups and datasets are
now proper `TableRef` instead of `ref Table` fields.
Although the content of these still needs to be looked at again...

It also introduces attrsJson iterators for H5 objects and a attrsToJson proc. These yield / return the attribute keys and their values as JsonNodes.

This change was long overdue.

HDF5 objects track all sorts of internal state to keep track of the
objects within the HDF5 C libray. This means for a large number of
operations, which don't change the given object from a user
perspective a `var H5*` object still had to be available, which often
meant having to declare e.g. a group or dataset as `var` although
apparently nothing that changes the objet would take place,
e.g. reading a simple dataset.

With every object being a `ref object` we kind of circumvent this,
because the immutability of a `ref object` refers to the reference
itself and not the object the reference points to.

Also from a more abstract point of view this makes a whole lot more
sense. These objects are not objects stored in a H5 file, but are
just *references* to objects in a file. Thinking about immutability of
such objects when the HDF5 C library does all sorts of crazy stuff in
the backend is almost ridiculous.

Also the tables, which store the different subgroups and datasets are
now proper `TableRef` instead of `ref Table` fields.
Although the content of these still needs to be looked at again...
It's still quite ugly in many ways, but better than before...

I hope it doesn't cause any weird recursions in cases I'm not testing,
due to the table refs in the objects.
For attributes the user often probably does not care too much about
the underlying type. In these cases just being able to quickly get all
attributes to look at / iterate over via JSON seems useful (it is for
me anyways).
Write dataset was broken due to the still remaining `var` arg of `create_dataset`
@Vindaar Vindaar merged commit ed0340c into master Nov 17, 2019
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

Successfully merging this pull request may close these issues.

1 participant