Friedrich Foerster wrote:
You have to keep the objects around either way. In Ben's case because you need the object to set the weight on it. In my case because you need the object to identify it with the model for setting the weight. It just is a matter of who you call the function on. The main simplification that Ben's method brings is that you don't need to worry about who contains a given Restraint. This might be enough to tip the scales.just my two cents to the conversation:- i would greatly appreciate if the usage is as simple and intuitive as possible. the end users will ideally be biologists if imp should really have significant impact. for that purpose i would rather not prefer to see all kinds of pointers floating around on the python level. from that point of view i vastly preferred option 1 of ben's original proposals.
an example: volume exclusions are often modelled as r^-12 potential (eg in modeller, i think). if i intend to use such an expression, it will be much more sensible to change the radius during optimization - and that's what our great hero frank actually did. so it would make sense to access them the same way, i argue.OK, but then they should be used in the same way--it is the restraints responsibility to have a weight field or not and handle it properly and the framework can't really touch it. The nice thing about treating weight differently from things like radius is then weight can be handled in a very standard manner and people who write restraints don't have to worry about handling it properly.