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