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

Re: Helper functions Correction

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