I lied. The second proposal doesn't give us everything we want as there is no well-defined GeometricParticle to cast to. So the first or no multiple inheritance are the only two options. And I would favor keeping it simple for now as much as I want to be able to mix things together.
On Nov 2, 2007, at 10:56 PM, Daniel Russel wrote:
> 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