Thanks Stefano for not getting (too!) pissed off with me. :-) We still don't have the clear API guidelines you asked for last time, but I think that these discussions are clarifying things for me at least, and we could probably start writing something up.
I was thinking that your idea is similar to the rationale behind OBStereoFacade. Well, simply put, we could have an OBResidueFacade class which you initialise with a molecule and behind the scenes it then stores the Atom->PDBAtomId correspondance in a map or vector by iterating over the residues. Then you would have the same method you described, but it wouldn't do any iteration, but just look up the Id in the std::map or vector. So, it's a convenience class, separate from the core API, and it's efficient. If no-one disagrees and this makes sense to you, do you want to have a go at writing it? - Noel On 25 February 2017 at 23:03, Geoffrey Hutchison <geoff.hutchi...@gmail.com> wrote: >> 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
