Skip to content

methods to manipulate atom types in ReactionManipulator - #883

Merged
johnmay merged 2 commits into
cdk:masterfrom
uli-f:reaction_manipulator_add_atom_type_config
Aug 26, 2022
Merged

methods to manipulate atom types in ReactionManipulator#883
johnmay merged 2 commits into
cdk:masterfrom
uli-f:reaction_manipulator_add_atom_type_config

Conversation

@uli-f

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

Copy link
Copy Markdown
Member
  • 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

@egonw egonw left a comment

Copy link
Copy Markdown
Member

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

uli-f commented Aug 26, 2022

Copy link
Copy Markdown
Member Author

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

egonw commented Aug 26, 2022

Copy link
Copy Markdown
Member

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

uli-f commented Aug 26, 2022

Copy link
Copy Markdown
Member Author

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

uli-f commented Aug 26, 2022

Copy link
Copy Markdown
Member Author

Added tests now.
Looking forward to feedback 😃

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

@egonw egonw left a comment

Copy link
Copy Markdown
Member

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

johnmay commented Aug 26, 2022

Copy link
Copy Markdown
Member

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.

3 participants