A number of people have found score states confusing both because the name doesn't really suggest much useful as well as because it is not obvious that they are the place to look if you want to implement a constraint. To address this several of us came up with a few proposed changes:
- rename ScoreState to ModelState. This rename would make the names consistent with OptimizerStates (XStates maintain state associated with X) and get rid of the idea that they have something direct to do with scoring. It also could be done trivially in all user code that uses ScoreStates via "sed -i.old 's#ScoreState#ModelState#g' **/*.h **/*.cpp **/*.py".
- Create a new base class Constraint which inherits from ModelState. The new base class wouldn't (necessarily) add any functionality, but it would provide a place in the documentation to discuss "constraints" as defined by the Sali lab and label ModelStates that are constraints as such. We would have to decided whether to rename existing XScoreStates which are constraints to XConstraint. These renames should, I think, be accomplishable through sed and hence not too painful.
- Continue with hiding ModelStates from the basic user experience. Currently, one should not have to know what they are and what they do unless you are implementing code for IMP. The documentation doesn't reflect this yet (as it was not originally the case). I'll work to further mark them as advanced.
Comments? Thoughts? Opposition?