> If each model had its own array or vector of list of atoms, none of > this would be a problem.
For small molecules that is not a problem. For macromolecules it could be a problem. > How about a method that just returns an array of atom indexes for a > particular model. As long as the implementation is forced to have > sequential atom indices it would just return an array of sequential > numbers. If, down the line, the implementation changes, we would not > have to get into too many problems :-). Perhaps. I frankly think that the most appropriate thing to do is to return an atom index and a count. We are not going to be dynamically adding any atoms to Jmol in the near future. And it would require substantial API changes. > Then another question pops up: do we need something like that for > bonds, and other multiple-atom spanning type of information... Starting > to get tedious. Yikes! Bonds are a little different ... because people will be able to add and subtract bonds. But, you are right, we need something similar for bonds. Maybe we should just write iterators to return the atoms in a model and to return the bonds in a model. That might resolve the issue. >>> If one were to write a multi-step xyz file for a subset of >>> models in the input, one would have to loop through all atoms for >>> every >>> model to be output in a step... >> >> I agree that it is not pretty. But in reality the cost of this >> iteration >> is insignificant. > > I agree, but I think that if one has to implement this kind of > iterations in different locations, it may be useful to fold in that > functionality directly at a lower level. You are exactly right. > Actually I would not even have dared to modify the JmolViewer class. (I > learned my lesson :-). :-) Miguel ------------------------------------------------------- The SF.Net email is sponsored by: Beat the post-holiday blues Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt _______________________________________________ Jmol-developers mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/jmol-developers
