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

methods to manipulate atom types in ReactionManipulator #883

Merged
merged 2 commits into from Aug 26, 2022

Conversation

uli-f
Copy link
Member

@uli-f uli-f commented Aug 26, 2022

  • added methods to perceive and unset the atom type configurations in ReactionManipulator
  • fixed a javadoc errors wrt content in AtomContainerManipulator#percieveAtomTypesAndConfigureUnsetProperties

… ReactionManipulator

- fixed a javadoc errors wrt content in AtomContainerManipulator#percieveAtomTypesAndConfigureUnsetProperties
Copy link
Member

@egonw egonw left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please add test methods for all new methods. And thanx for the extensive documentation!

@uli-f
Copy link
Member Author

uli-f commented Aug 26, 2022

Please add test methods for all new methods.

I decided against adding tests as the methods merely combine two (already tested) method calls. There is not logic in those methods other than a for loop.

I am happy to add tests if that is what you prefer (e.g., to achieve good test coverage numbers).
Just let me know and I am on it.

@egonw
Copy link
Member

egonw commented Aug 26, 2022

I decided against adding tests as the methods merely combine two (already tested) method calls.

Understood. But... we write unit tests as much as now as for the future. The implementation is now simple, but in the future may not. I found it much more beneficial for maintainability if all assumption are explicit. It fixed a lot of code in the 2003-2008 period, even the silliest unit tests.

@uli-f
Copy link
Member Author

uli-f commented Aug 26, 2022

Understood. But... we write unit tests as much as now as for the future. The implementation is now simple, but in the future may not. I found it much more beneficial for maintainability if all assumption are explicit. It fixed a lot of code in the 2003-2008 period, even the silliest unit tests.

Okay, I see your point.
Will add (simple) tests now.

- added null pointer checks for perceiveAtomTypesAndConfigureAtoms, perceiveAtomTypesAndConfigureUnsetProperties, and clearAtomConfigurations
@uli-f
Copy link
Member Author

uli-f commented Aug 26, 2022

Added tests now.
Looking forward to feedback 😃

@egonw egonw self-requested a review August 26, 2022 13:57
Copy link
Member

@egonw egonw left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for adding the tests.

@johnmay
Copy link
Member

johnmay commented Aug 26, 2022

Looks fine, personally I don't think we use wildcard imports anywhere else mainly for convention. In the restricted case of org.openscience.cdk.interfaces.* I guess it is fine. It would be marginally more efficient to loop the component types rather than use the less efficient getAllMolecules. The fastest toolkits represent reactions as molecules anyways and so technically it's already possible to do it like this:

java
IReaction rxn = ...;
IAtomContainer mol = ReactionManipulator.toMolecule(rxn);
AtomContainerManipulator.percieveAtomTypesAndConfigureAtoms(mol);
rxn = ReactionManipulator.toReaction(mol);

Although that would be pretty silly :-).

@johnmay johnmay merged commit e1ac1f7 into cdk:master Aug 26, 2022
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.

None yet

3 participants