Noel,
quite the contrary, I'm far from being pissed at you, by all means.
I like your suggestion, but I don't know if I can do it right away, there are
still a few
things about the facade programming paradigm that escape my hobbist programming
training.
Following up on the discussion about the hydrogen bond, I had a quick chat with
one of my
students which is starting to write code based on OpenBabel.
We took a shot at designing an OBHBondTyper class which should behave similarly
to
OBAromaticTyper, and my idea was to store the information in a vector.
If I'm not mistaken, though, the aromatic typer works in a lazy way that looks
similar to
what you're describing for the OBResidueFacade, storing the information in a
flag instead
of a vector, is that correct? Or is the flag is just in vector? I tried looking
for the
definition of HasFlag(), but I couldn't find it.
Either way, I was thinking to start by writing this HB class (which I probably
understand
better), try implementing the ob-standard lazy evaluation mechanism, and
integrate it the
[Begin|End]Modify() process.
We can do a git pull and then fix and adapt it according to the feedback other
developers
suggestions.
This would be a great chance for us to understand how to contribute code that
would
integrate better and match the guidelines you guys follow.
Thanks (for the patience),
S
On 02/26/2017 02:05 AM, Noel O'Boyle wrote:
> 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
--
Stefano Forli, PhD
Assistant Professor of ISCB
Molecular Graphics Laboratory
Dept. of Integrative Structural
and Computational Biology, MB-112A
The Scripps Research Institute
10550 North Torrey Pines Road
La Jolla, CA 92037-1000, USA.
tel: +1 (858)784-2055
fax: +1 (858)784-2860
email: fo...@scripps.edu
http://www.scripps.edu/~forli/
------------------------------------------------------------------------------
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
