There are a couple questions which need to be resolved before redo particles.
1) Multiple inheritance It would be nice to be able to arbitrarily mix and match Particle types-e.g. if we have a GeometricParticle and a HierarchyParticle to be able to produce a GeometricHierarchyParticle by inheriting from both. This causes several complications: Either: - We have a Particle base class which contains a ModelData pointer (and a bool for active, although I am still not entirely sure what this does). Then we have to use virtual inheritance (which people are probably not that familiar with) and (unless we disallow multiple inheritance of anything derived from Particle) careful bookkeeping on IO (I think C++ gets the constructors and destructors right for us)
- Use templates. When you want to declare a new particle type you declare it as template <class ParentParticle=Particle> struct NamedParticle: public ParentParticle { NamedParticle(ModelData* md): Parent(md){ IMP_ALLOCATE_STRING_ATTRIBUTE(name); // something like string_name_index_= ParentParticle::get_model_data()->add_string("") } IMP_STRING_ATTRIBUTE(name); // declares void set_name(String), String get_name() and StringIndex string_name_index_ virtual void show(std::ostream &out) const { IMP_SHOW_STRING(name); // out << "name: " << ParentParticle::get_model_data()- >get_string(string_name_index_) << std::endl; }
}; Then if you want a composite type you declare typedef GeometricParticle<NamedParticle<> > GeometricNamedParticle;
Not sure what we would do with this in Python. Perhaps just export the most derived particle types (and Particle) as those are all that can be used anyway. Python wouldn't then have to deal with the inheritance hierachy. This approach has all the nice properties we want, but requires that people use templates. Since particles are likely to be fairly simple, using templates might not be too bad.
- or we could disallow multiple inheritance all together. Doing so certainly simplifies things, but makes we worry that things would get too rigid or duplicated too much.
2) IO Currently particles can be trivially read from an XML file since there is only one object type and an easy mapping between attribute names and function calls. Things get more complicated on reading with Particles as objects since we have to figure out how to create the correct type of Particle. There are ways of doing this which can probably be done more or less invisibly within C++ (but I don't want to write test code for them). But we may want to see if there is some library which makes things cleaner. Perhaps doing everything through python pickling? We want to be able to support both python and C++ declared particles, I think.
On Nov 2, 2007, at 6:12 PM, Ben Webb wrote:
> Daniel Russel wrote: > (excellent summary snipped) >> Personally I think the class based approach is better, but Brett >> liked databases and went with the former. The one thing I think we >> should not do is mix the two. Either everything is an object and >> you get things through C++ calls or everything is as it is >> currently and you manipulate things through helper functions. If >> we mix, it is hard to keep track of what everything is and make >> sure that things like saving and restoring state happen properly >> as well as just being ugly. > > I agree 100%, and I guess I wasn't being very clear in my previous > emails, because this is exactly my position. We can do attributes, > or we can do objects, and shouldn't mix them. If it becomes clear > that we have to switch from attributes to objects, I'd much rather > we do that now, because it'll be really hard to do it later. > > Ben > -- > ben@salilab.org http://salilab.org/~ben/ > "It is a capital mistake to theorize before one has data." > - Sir Arthur Conan Doyle