> About the PDB atom name, unfortunately I don't fully understand the > performance issue implied in my suggestion, but from an interface point of > view, it seems more intuitive to access an atom property from OBAtom instead > of going back to the OBResidue (and pass the OBAtom).
The OBAtom should already have a pointer to the OBResidue. If it can be done with generic data in the OBAtom, that's fine, but I don't think I want to add data to each OBAtom. If I translate a nanotube or nanoparticle (or any other non-biomolecule) I'd have to store in memory a bunch of residue pointers that would never get used. > In this case, the best approach I can think of is to write a OBHBondTyper > class to perceive the hbond character (similarly to what OBAromaticTyper > does), then each atom should have a simple IsHBond() method that would return > 0, 1 (donor), 2 (acceptor), 3(donor/acceptor), 4(...?). Yes, this is the way to go to add "convenience functions." Noel's suggestion is to keep the core API restrained, but that doesn't mean there can't be convenience classes or static methods. I think HBondTyper would be a good example, since there can (and should) be multiple models of "what is a hydrogen bond." > At the same time, I support Maciek's idea: useful functions that can > streamline the use of scripting languages such as Python should be grouped > and conserved. I'm not sure why these can't be put into wrappers like Pybel. As is, there is considerable "helper code" in Pybel, etc. -Geoff ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, SlashDot.org! http://sdm.link/slashdot _______________________________________________ OpenBabel-Devel mailing list OpenBabel-Devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openbabel-devel
