![](https://secure.gravatar.com/avatar/f242853dd4064d5ec26005ca96a58a64.jpg?s=120&d=mm&r=g)
I find it currently somewhat confusing what the order of arguments is to restraints and score function constructors. I propose establishing the convention that the unary function or the score function is always first. Such a convention has several advantages: - it makes it easier to get the thisown line in IMP.i right - the remainder of the arguments are less consistent, but everything takes and owns a score function or a unary function - the score function is needed for the restraints, other things are less important - we can then make the other arguments option. For example, I generally create restraints before I know the particles they will act on (since those change), so I create them with an empty list of particles. It would be a minor convenience to be able to omit this
I'll make the changes if no one objects. It should take only a few minutes.
![](https://secure.gravatar.com/avatar/cfe8857a24d561e8e700ab18e3ba7ec8.jpg?s=120&d=mm&r=g)
Daniel Russel wrote: > I find it currently somewhat confusing what the order of arguments is > to restraints and score function constructors. I propose establishing > the convention that the unary function or the score function is always > first. Such a convention has several advantages:
Sounds fine to me. The convention should probably be documented in Restraint.h and perhaps the score function headers so that people don't forget, though.
Ben
participants (2)
-
Ben Webb
-
Daniel Russel