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

Shared methods could be defined as traits #34

Open
jbarnoud opened this issue Feb 18, 2023 · 2 comments
Open

Shared methods could be defined as traits #34

jbarnoud opened this issue Feb 18, 2023 · 2 comments

Comments

@jbarnoud
Copy link

The Frame and the Topology structs share methods to access and modify the topology of a system. These methods, defined as a trait, would allow writing functions that can accept both a Frame and a Topology. Having more than one trait would also allow sharing methods with TopologyRef.

From a quick look at the documentation, I would suggest two traits:

  • AccessTopology could be defined for Topology, TopologyRef, and Frame. It could have the following methods:
    • atom
    • size
  • MulateTopology could be defined for Topology and Frame and have:
    • atom_mut
    • resize
    • add_atom
    • remove
    • add_bond
    • add_bond_with_order
    • remove_bond
    • add_residue
    • clear_bonds

Counterintuitively, neither Topology nor TopologyRef have iter_atoms, which would work well in the AccessTopology trait. Since Frame does not have any method to access residues, bonds, angles, or dihedrals (bond, angle, and dihedral return the measure of the connection, not the connection itself), the AccessTopology trait could also be named AccessAtoms.

With these traits, it would be possible to write code like:

fn do_something_with_the_atoms(source: &impl AccessTopology) {
    for atom in source.iter_atoms() {
        // something
    }
}

fn main() {
    let frame: Frame = ...;
    let topology: Topology = ...;
    do_something_with_the_atoms(frame);
    do_something_with_the_atoms(topology);
}

If there is interest, I'd be happy to work on a pull request.

@Luthaf
Copy link
Member

Luthaf commented Mar 29, 2023

Sorry for the delay in answering this. I understand the appeal of making the code nicer with generic function, but I have a hard time thinking of use cases where one would want to modify either a frame or a topology with the same code. Do you have a specific use case where these traits would help?

Also, we don't implement DerefMut from Frame to topology because one could use this to resize the topology without resizing the frame, but I could see a TopologyRefMut with bonds/residue manipulation functions.

@jbarnoud
Copy link
Author

I thought I had a use case when I did not know if I were going to use a Frame or a Topology to access the bonds in my system. Ultimately, I am not sure I would really have used the genericity, in that project at least.

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

No branches or pull requests

2 participants