I'd like to get a consensus on naming for IMP modules and classes
(well, OK, I'm going to say what I think it should be, and people
can agree or disagree).
Currently, on the C++ side, all classes use a
Capitalized_Words_With_Underscores naming scheme (e.g.
Restraint_Set) and live in the 'imp' namespace. This is translated
to the 'imp2' module on the Python side, with the same class names.
This has a few problems:
1. The Python 'imp2' name is ugly - Bret presumably had to call it
that because Python has a built-in module called 'imp' already. The
Python guys (http://www.python.org/dev/peps/pep-0008/) prefer
"short, lower-case" names for modules, but I don't think this
really makes sense for initialisms anyway - for example, there are
already EMAN and CORBA Python libraries out there (the BALL guys
also use "BALL"). So I propose "IMP".
yes
2. Python pretty much mandates CamelCase for class names (e.g.
RestraintSet). Since the Python class names match the C++ names, we
either have to do lots of ugly renaming in the Python interface, or
just rename the C++ classes to match. Lots of C++ people use
CamelCase anyway (e.g. BALL at http://www.bioinf.uni-sb.de/OK/BALL/Documentation/1.1.1/V1.1.1/hierarchy_html). So I propose CamelCase
names for IMP C++ classes.
I use CamelCase
We should probably have some consensus on function names and
attribute names I would go with:
get/set ( Daniel's convention):
protected:
int x_;
public:
int x() const {return x;}
void set_x(int x) { x_=x;}
and thus all class attributes should be name_ as well ( just to stay
consistent)
and for other functions I would use CamelCase as well
3. There are a bunch of utility Python modules in tests/
python_libs: IMP_Modeller_Intf.py IMP_Test.py IMP_Utils.py
load_imp_xml_model.py
I propose renaming these to IMP.modeller, IMP.test, IMP.utils,
IMP.xml.
yes
4. I propose renaming derived classes such as
imp::RSR_Exclusion_Volume (exclusion volume restraint, although
what the second R in RSR stands for, I don't know ;) as either
imp::ExclusionVolumeRestraint or imp::restraint::ExclusionVolume. I
prefer the latter because it would more easily translate into the
Python IMP.restraint.ExclusionVolume class, and by changing from a
class name prefix (RSR) to a namespace we both allow for more
readable Python scripts (e.g. "import IMP.restraint as r;
r.ExclusionVolume()" or even "from IMP.restraint import *"), and
finally because this would greatly simplify moving restraints to
their own C++ module.
I would go with imp::ExclusionVolumeRestraint and imp::CGOptimizer -
to make it more self explanatory
5. using namespace
are we ok with using namespace std for the IMP classes ??
6. public/protected/private
I think that all attributes that can be derived should be protected
and other internal attributes ( like for example was_calculated )
What do others think?
Ben
--
http://salilab.org/~ben/
"It is a capital mistake to theorize before one has data."
- Sir Arthur Conan Doyle