Re: Helper functions

[Daniel Russel <>]

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
> --
>                       http://salilab.org/~ben/
> "It is a capital mistake to theorize before one has data."
> 	- Sir Arthur Conan Doyle