It's more that clone() is an indication of bad style. Unfortunately a lot of the CDK (particularly the QSAR code) is built on the premise this is easy and cheap. Also all out *clone()* implementations throw *CloneNotSupported* when they shouldn't this leads to ugly try/catch down stream.
It is true there isn't a viable alternative for a deep copy and having a *AtomContainerManipulator.copy()* for example would help, ideally the copy constructor should have been a deep copy (it's currently a shallow). John On Tue, 30 Oct 2018 at 16:50, Christoph Steinbeck < christoph.steinb...@uni-jena.de> wrote: > > > On 30. Oct 2018, at 17:15, John Mayfield <john.wilkinson...@gmail.com> > wrote: > > > > 2) Looks like a bug, but you really really really should not be using > clone. > > You also say that in https://github.com/cdk/cdk/wiki/AtomContainer2, > which is a great guidance, apart from indicating alternatives cloning for > the less enlightened :) > > The only alternative to cloning is to write code which comes down to a > custom clone method, or not? i.e. you create a new AtomContainer and copy > over the objects that you need for your algorithm, by, say, instantiating > new atoms with identical properties, and adding them to the AC. > > Is your argument that clone does a lot more work than one might need in > one's specific case? > > Kind regards, > > Chris > > — > Prof. Dr. Christoph Steinbeck > Analytical Chemistry - Cheminformatics and Chemometrics > Friedrich-Schiller-University Jena, Germany > Phone Secretariat: +49-3641-948171 > http://cheminf.uni-jena.de > http://orcid.org/0000-0001-6966-0814 > > What is man but that lofty spirit - that sense of enterprise. > ... Kirk, "I, Mudd," stardate 4513.3.. > >
_______________________________________________ Cdk-user mailing list Cdk-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/cdk-user
