Since my emails are long, here in brief are the ideas (which can be
chosen independently):
1) forget about function generators and just make the restraints shift
the distance value itself before calling the ScoreFunc. Then each
restraint just has one ScoreFunc and so modifications to it (such as
reducing its stiffness) are easy.
2) separate the choice of pairs of particles from the actual
computation on the pair. So we have a set of restraints each of which
applies a computation to a differently generated set of pairs and a
set of computation functions each of which simply computes on a pair.
I certainly agree that reducing the number of objects is a good thing.
But I'm not sure what you're proposing for (1). Let's say you want an LJ
restraint (but let's pretend we can model it with a harmonic term, since
we have that already). So this would need to iterate over all pairs of
atoms (potentially via a nonbonded list). This you propose should be in
the restraint (as it is now, but at evaluate rather than constructor
time). Yes?
But what happens next? As I understand it, you propose that this
restraint would have a single harmonic ScoreFunc and a single Pair
function. Restraint.evaluate calls Pair.something() for each pair, which
calculates the distance and then the score. But it's this last step
which I'm unclear on. Where do the mean and the stdev (or width or
stiffness) live? They are different for every atom pair, so they surely
can't live in the ScoreFunc if you have only one. Maybe some pseudocode
would elucidate this.