On Dec 16, 2008, at 11:56 AM, Dina Schneidman wrote:
> no need to add, works just fine. Constructing it directly is slightly unsafe as a few method assume that the keys are initialized in a given order (the problem is unlikely to arise, so go ahead until the patch is committed).
I stuck a patch in kernel/doc/patch to added methods to safetly construct keys from PDB strings (it requires a minor change to Key.h). The new methods check to make sure the atom and residue names are standard ones.
> > thanks! > > On Tue, Dec 16, 2008 at 11:48 AM, Daniel Russel drussel@gmail.com > wrote: > > On Dec 16, 2008, at 11:40 AM, Dina Schneidman wrote: > > Hi, > > is there any reason that ResidueTypes and AtomTypes are defined as > static variables, rather than enum? > Having them as static variables means you have a proper type > associated with the identifiers, which is kind of nice. It also > means that you can add your own residue names and have the mapping > to a string accessible to i/o code. > > > > > what is the best way to map between ResidueType and the PDB residue > name string and the same for atoms? > ResidueType("pdbname") should work for now. Same for AtomType. > > I think I should add a function residue_type_from_pdb_name and > atom_type_from_pdb_name to provide a cleaner and clearer route. I'll > check in such code shortly. > > > thanks! > Dina > > _______________________________________________ > IMP-dev mailing list > IMP-dev@salilab.org > https://salilab.org/mailman/listinfo/imp-dev > > _______________________________________________ > IMP-dev mailing list > IMP-dev@salilab.org > https://salilab.org/mailman/listinfo/imp-dev > > _______________________________________________ > IMP-dev mailing list > IMP-dev@salilab.org > https://salilab.org/mailman/listinfo/imp-dev