You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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:
fndo_something_with_the_atoms(source:&implAccessTopology){for atom in source.iter_atoms(){// something}}fnmain(){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.
The text was updated successfully, but these errors were encountered:
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.
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.
The
Frame
and theTopology
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 aFrame
and aTopology
. Having more than one trait would also allow sharing methods withTopologyRef
.From a quick look at the documentation, I would suggest two traits:
AccessTopology
could be defined forTopology
,TopologyRef
, andFrame
. It could have the following methods:atom
size
MulateTopology
could be defined forTopology
andFrame
and have:atom_mut
resize
add_atom
remove
add_bond
add_bond_with_order
remove_bond
add_residue
clear_bonds
Counterintuitively, neither
Topology
norTopologyRef
haveiter_atoms
, which would work well in theAccessTopology
trait. SinceFrame
does not have any method to access residues, bonds, angles, or dihedrals (bond
,angle
, anddihedral
return the measure of the connection, not the connection itself), theAccessTopology
trait could also be namedAccessAtoms
.With these traits, it would be possible to write code like:
If there is interest, I'd be happy to work on a pull request.
The text was updated successfully, but these errors were encountered: