or model.set_weight(myrestraint_index, .5) or
or restraintset.set_weight(r, .5);
I don't like the second because it requires the model to keep a second
bunch of restraint pointers hanging around, and then you have to keep
them synchronized with the 'real' list of restraints (what happens if
you remove a restraint from a model, or you delete a restraint and
create a new one which happens to have the same address?) I _really_
don't like the first one because 1) it requires the list of restraints
to remain ordered and 2) it wouldn't work with restraints that live
inside other restraints.
They just require that either the model/RestraintSet (for the first)
store the Restraint pointers in a vector of std::pairs with weights
and return the index (just like the Particles) or, for the second,
just in a map or any other container and go and find the correct
restraint when the weight is set. Simple enough. No duplications and
no significant overhead.
And the user has to keep around the identity of the restraints he is
interested in somehow anyway.
If you like the third, why not compromise and say just that any
RestraintSet can scale its children.
The third is the same as the first, just that both models and
restraint sets store lists of restraints.
Yes, I figured you'd say that. ;) On the other hand, adding a scale
member to the Restraint base class adds a per-object overhead, and
it's better to only have that for RestraintSets. So we can agree
put it in Restraint, but for different reasons...
Well, one word is pretty negligible. Especially with that mysterious
list of particles there already :-)
Sure. But that requires copying the object and keeping them
synchronized. Not that I see any particular application of this :-)
Maybe I'm missing something here, but a RestraintSet (currently) just
keeps a vector of pointers to Restraints. So there's no reason why the
same Restraint object couldn't be in two sets.
Yes, but if we store the weight in the Restraint, it can't really be
in two sets any more because the weights are linked.