Minor breaking change and a proposal for some other changes
First, AtomDecorator, ResidueDecorator etc. now inherit from MolecularHierarchyDecorator, on Javi's suggestion. This saves a lot of typing in most cases. Some existing code may break, but fixing it is simply a matter of removing a call the MHD::create (since a previous call to AtomDecorator::create added all the necessary data). See the change history for more details.
Second, I propose renaming MolecularHierarchyDecorator to HierarchyDecorator since it is in the atom namespace already. This would save a ton of typing as MolecularHierarchyDecorator is a bit ridiculously long. And, with the exception of people like me who do "using namespace IMP::atom", all user code could be updated with sed.
Thirdly, I propose removing coordinates from AtomDecorator. The reasons for this are mostly philosophical: we are trying to get away from people being fixed on atomic coordinates and it is only due to quantum mechanical details which have no bearing on what we do that they make any more sense than coordinates for any other level of the atom::Hierarchy. Also, having them makes the AtomDecorator a bit of a mess since it has to inherit from two other decorators.
Daniel Russel wrote: > Second, I propose renaming MolecularHierarchyDecorator to > HierarchyDecorator since it is in the atom namespace already. This would > save a ton of typing as MolecularHierarchyDecorator is a bit > ridiculously long. And, with the exception of people like me who do > "using namespace IMP::atom", all user code could be updated with sed.
Sounds reasonable to me.
> Thirdly, I propose removing coordinates from AtomDecorator. The reasons > for this are mostly philosophical: we are trying to get away from people > being fixed on atomic coordinates
We are? I was under the impression that we want to generate models as accurately as we can. That means atomic coordinates if possible. It's only if we can't manage that that we can settle for coordinates for domains, proteins etc.
> and it is only due to quantum > mechanical details which have no bearing on what we do
On the contrary, methods such as ONIOM or QM/MM could certainly be applied in IMP when we're dealing with atomic information, at least for part of the system. There's no reason why we should specifically exclude them.
> that they make > any more sense than coordinates for any other level of the > atom::Hierarchy.
On this I agree with you - if atoms have coordinates, then so should residues, chains, domains, proteins. It certainly seems reasonable therefore that *none* of these things should have coordinates "by construction" and that we just use an XYZDecorator (or an XYZRDecorator) if we want to additionally treat them as points or spheres.
> Also, having them makes the AtomDecorator a bit of a > mess since it has to inherit from two other decorators.
Well, that is true, but it seems reasonable to allow multiple inheritance in decorators - or at least, it seems unreasonable to preclude it.
Ben
> >> that they make >> any more sense than coordinates for any other level of the >> atom::Hierarchy. > > On this I agree with you - if atoms have coordinates, then so should > residues, chains, domains, proteins. It certainly seems reasonable > therefore that *none* of these things should have coordinates "by > construction" and that we just use an XYZDecorator (or an > XYZRDecorator) > if we want to additionally treat them as points or spheres. That was my thought. Having unused coordinated is bad and all levels should be equivalent.
> > Well, that is true, but it seems reasonable to allow multiple > inheritance in decorators - or at least, it seems unreasonable to > preclude it. The problem is just a practical one: either we use virtual inheritence or we have two particle pointers. Neither is very nice.
Daniel Russel wrote: >> Well, that is true, but it seems reasonable to allow multiple >> inheritance in decorators - or at least, it seems unreasonable to >> preclude it. > The problem is just a practical one: either we use virtual inheritence > or we have two particle pointers. Neither is very > nice.
Oh, of course - we have diamond inheritance. Ick, I agree.
Ben
participants (2)
-
Ben Webb -
Daniel Russel