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

[Feature]: Move shape, type, and is-required-field validation to outside of constructor docval #881

Open
3 tasks done
rly opened this issue Jun 27, 2023 · 0 comments
Open
3 tasks done
Assignees
Labels
category: enhancement improvements of code or code behavior priority: low alternative solution already working and/or relevant to only specific user(s)

Comments

@rly
Copy link
Contributor

rly commented Jun 27, 2023

What would you like to see added to HDMF?

Currently, compliance with the schema is checked in multiple places -- on write and on construction of a data_type object in the docval of the constructor. This includes type checking, shape checking, and enforcing that required values are passed in.

After #868 is merged, container attributes can be reassigned to values that are not compliant with the schema in the data type, shape, or whether the attribute is required. This can result in errors on write.

Is your feature request related to a problem?

No response

What solution would you like?

To be maximally flexible, type and shape compliance should be checked when the value is set in the setter. We can add a dtype and shape argument to the __fields__ class variable for each field that is referenced in each setter. Checking whether an object has all required fields is more complicated. It might be useful to have a validate method for each object that checks to see if all required attributes are present. This would get called in each setter when not being called from the constructor and once at the end of the constructor. The user could also call this, and this may be useful when validating external resources as well.

Do you have any interest in helping implement the feature?

Yes.

Code of Conduct

@mavaylon1 mavaylon1 added category: enhancement improvements of code or code behavior priority: low alternative solution already working and/or relevant to only specific user(s) labels Sep 11, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
category: enhancement improvements of code or code behavior priority: low alternative solution already working and/or relevant to only specific user(s)
Projects
None yet
Development

No branches or pull requests

2 participants