[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Helper functions

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