On 10/11/2011 17:40, Igor Filippov [Contr] wrote: > >> The confusion caused by too much choice and the deficiencies in all of >> the above mean that MolCore API (the proposed re-writing of the central >> part of the toolkit) deserves better. I am pushing for no atom indexes >> at all, and only one way for a user to reference an atom - a sort of >> atom pointer which remains valid whatever you do to the molecule. It is >> also an iterator that can be can be incremented in various interesting >> ways. > > I don't want to be a naysayer but I think it's a horrible idea. > I've had numerous problems with the current implementation of atom/bond > iterators, if they are going to remain the only way to loop through > atoms/bonds it will be very difficult if not impossible to manipulate > OBMol to the degree that I need. > > I would urge leaving things that work well enough alone and concentrate > on fixing stuff that's broken - for example 2.3.1 broke static > compilation on OSX and MinGW yet again, I haven't heard back any > comments regarding that.
I hope you don't mind a harmless drudge getting some relaxation by speculating on what might be in a new program (not the next version of OB). As well as the difficulties with manipulating molecules in OB implied above, I also am irked by having to use bonds when what I need are connections and having to remember in what order you construct, specify and incorporate atoms and bonds. I would be interested to hear of what features of the iterators you do not like. I'll try to put up a demo of the AtomPtr idea soon, so that there can be more focused criticism. Solving the problems with static builds and MinGW, which I suspect are are of interest to a minority of users, really needs input from a developer who is using these features. Do you know of anyone willing to help? Chris ------------------------------------------------------------------------------ RSA(R) Conference 2012 Save $700 by Nov 18 Register now http://p.sf.net/sfu/rsa-sfdev2dev1 _______________________________________________ OpenBabel-Devel mailing list OpenBabel-Devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openbabel-devel
