> 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. Igor ------------------------------------------------------------------------------ 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
