On Jan 21, 2009, at 6:13 PM, Daniel Russel wrote:
> The reasons I left it non-const are > - we currently don't pass around pointers to const Objects anywhere > (all the containers give you back non-const objects and all the > functions take non-const ones) > - there is no concept of const in python We still have a lot of functions on the c++/swig interface that are const - why should apply be special ? > > - it is useful to be able to do things like count the number of > particles with a given property in the modifier without declaring > the counter mutable (yes, it isn't necessarily a modifier then) > - restraint::evaluate is non-const and that is a similar function. > On the other hand UnaryFunction::evaluate is const, so we are not > very consistent. > > Anyway, I am fine either way. If we want to switch it I can do it as > part of moving the base classes to the kernel. > I think that it makes sense for a function like modifier::apply and restraint::evaluate to be const - but this is major change in the interfaces of base classes - so we should get agreement from Ben as well for that. > > On Jan 21, 2009, at 5:49 PM, Keren Lasker wrote: > >> can we change the apply function to const ? >> The only thing that should change as a result of the apply function >> is the state of the Particle and not the Modifier itself. >> >> _______________________________________________ >> IMP-dev mailing list >> IMP-dev@salilab.org >> https://salilab.org/mailman/listinfo/imp-dev > > _______________________________________________ > IMP-dev mailing list > IMP-dev@salilab.org > https://salilab.org/mailman/listinfo/imp-dev