Hi Noel,
I'm in, too.
Spotting these convoluted approaches may be a great opportunity to identify
places where the API should be streamlined.
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).
That would address the issue of the performance as well, right?
To use another example where my convoluted approach raised the issue [a good
thing, I guess, one way or another], functions like OBAtom::IsHBAcceptor()
OBAtom::IsHBDonor() are big and convoluted convenience functions, because to do
the proper classification, there are several cases that need to be tested.
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(...?).
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.
S
--
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: [email protected]
http://www.scripps.edu/~forli/
________________________________________
From: Maciek Wójcikowski [[email protected]]
Sent: Saturday, February 25, 2017 3:21 AM
To: Noel O'Boyle
Cc: Openbabel-DEV
Subject: Re: [OpenBabel-Devel] Convenience functions
Hi Noel,
I agree with you and must say that in 99.99% of cases it's the right way to do.
Although I still believe the convenient functions, especially the ones that
loop over stuff, are extremely useful when called from Python - they are just
so much faster. I'd be happy with some external place where we could keep them.
+1 from me.
----
Pozdrawiam, | Best regards,
Maciek Wójcikowski
[email protected]<mailto:[email protected]>
2017-02-25 10:33 GMT+01:00 Noel O'Boyle
<[email protected]<mailto:[email protected]>>:
Hi there,
As some of you know, I would like to remove all convenience functions
from classes in Open Babel. I would like to explain why.
It's hard to exactly define a convenience function, but it's an
addition to the API that is implemented entirely using existing API
calls and that makes it easier to do certain things. There may be a
place for these in the documentation (e.g. usage examples as OEChem
does) or in a convenience.cpp, but I argue that they should never be
part of any Open Babel classes, and in particular, should never be
used internally by the API.
One reason is that it clogs up the core API, which affects both
compilation speed and reading the API looking for functions. It's also
API duplication - there should be one way to do something. Also, there
are a infinite number of convenience functions and once you let one in
(e.g. OBAtom::IsCarbon()), you must then let in 100+ other ones.
A more subtle reason is that they obscure the correct usage of the
underlying core API, as users cannot know they are convenience
functions. Sounds a bit vague? Here are two examples.
Let's take the duplicated std::string versus const char* functions I
mentioned in an earlier email. The std::string version just calls the
const char* function. Some of these convenience functions do an
unnecessary string copy. On top of this, a user of the toolkit, having
a char* to hand but needing to choose between the methods, may
construct a std::string (another copy) to call the std::string method
because stack overflow tells us to always use C++ STL objects. So,
adding the convenience functions had the unintended consequence of two
string copies.
Another example is the convenience function that Stefano has proposed
that loops over the Residues to return the PDBAtomId for an OBAtom. I
don't disagree this is useful, but it's still a convenience function.
Now imagine a user who writes a loop over all the atoms in a molecule
calling this function. They end up using an N squared function, which
is going to be a fairly significant slowdown for PDB files. But there
was no way for them to know that this was not the correct method to
call.
The current API has many such convenience functions. Let's make a
bonfire (e.g. called convenience.cpp) and burn them all.
- Noel
------------------------------------------------------------------------------
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
[email protected]<mailto:[email protected]>
https://lists.sourceforge.net/lists/listinfo/openbabel-devel
________________________________
NOTE: This message was trained as non-spam. If this is wrong, please correct
the training as soon as possible.
------------------------------------------------------------------------------
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/openbabel-devel
