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

RFC: use keyword args for setting properties #632

Merged
merged 3 commits into from
Aug 24, 2020

Conversation

kleinhenz
Copy link
Contributor

I decided to try this while looking at #631. This replaces the current method of setting properties using varargs with keyword arguments. This is breaking so we should discuss if it is worth it. In #462 where the current behavior was introduced it looks like this wasn't done because the behavior of keyword arguments was still stabilizing in julia. Now that julia has stabilized I think this is a better interface.

@musm
Copy link
Member

musm commented Aug 16, 2020

This is definitely the correct way to go. I wonder about switching from strings to symbols. Any particular reason to change that?

I'm not sure on how best to handle the breaking change, but I definitely want to see this in.

@kleinhenz
Copy link
Contributor Author

The key type of the slurped kwargs is a symbol so I just wanted to avoid an unnecessary conversion to a string. This changes the case where you set a property explicitly e.g. apl[:fclose_degree] = H5F_CLOSE_STRONG but in the common case where the properties are set by using the kwargs this should be invisible.

@musm
Copy link
Member

musm commented Aug 17, 2020

Makes sense. Would it be ok to merge this and make a breaking release? I don't see an obvious way of making this non-breaking or adding a deprecation message given how the previous structure was coded.

@musm
Copy link
Member

musm commented Aug 17, 2020

Perhaps we should add a major note in the README

@kleinhenz kleinhenz force-pushed the kwargs_props branch 2 times, most recently from 23822e2 to 570d632 Compare August 18, 2020 03:30
@kleinhenz
Copy link
Contributor Author

Yeah a breaking release is probably the way to go. I can't think of a great way to deprecate this either. I added a HISTORY.md file to keep track of changes between versions.

@musm
Copy link
Member

musm commented Aug 18, 2020

We'll also need to update the syntax in the docs, ref https://github.com/JuliaIO/HDF5.jl/blob/master/docs/src/index.md

@kleinhenz
Copy link
Contributor Author

Updated the documentation for this. The new docs look great BTW!

@musm
Copy link
Member

musm commented Aug 21, 2020

I think I will first merge 978050c after reviewing it. Make a minor release. Then merge this and make a breaking release. Any objections?

@musm
Copy link
Member

musm commented Aug 21, 2020

Also just want to say this is a massive improvement over the very old style of 'keyword' handling that HDF5 is using (very legacy)

@kleinhenz
Copy link
Contributor Author

Makes sense to me. It also probably makes sense to try merge #643 before the minor release to get the ci passing again.

@musm
Copy link
Member

musm commented Aug 24, 2020

On second thought I think we should just merge this first and the following PRs and include them in the major release. That way if code magically breaks due to someone relying on internals it won't be an issue.

jmert added a commit to jmert/HDF5.jl that referenced this pull request Sep 11, 2020
musm pushed a commit that referenced this pull request Sep 14, 2020
* Add deprecated bindings for backwards compatibility with ecosystem packages

Namely, get the tests of JLD.jl and MAT.jl to pass again.

* Deprecations for #632 - keywords instead of property lists

* Deprecations for #652 - generic read

* Deprecate {d,a}_{create,write} methods with property lists

The calls should use keyword properties instead.
coroa added a commit to coroa/GlobalEnergyGIS that referenced this pull request Mar 5, 2021
JuliaIO/HDF5.jl#632 switched properties to keyword arguments.
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.

2 participants