I guest IMolecule would be useful in cases like this, sigh.
From looking at the subclasses of IAtomContainer, IRing should be the only one which causes problems as it's the only one which is a sub-container.
IStrand (looks old c. 2004)
On 7 Jun 2012, at 14:28, gilleain torrance wrote:
> Hi John,
> I've seen this also in various libraries (eg Residue objects with refs
> to Chains, and Atoms with refs to Residues) there are certainly
> benefits to the approach.
> However, it also has limitations : you either have to have a list of
> parents, or lose the ability to have a single atom in two atom
> containers. In the CDK an atom container is not a molecule, but could
> be a ring or a fragment or something else. Two overlapping fragment
> atom containers in the same molecule would share atoms.
> I'm not saying that it's a bad idea, just that it has some costs
> associated with it, as well as benefits.
> On 6/7/12, John May <johnmay@...> wrote:
>> Hi all,
>> I'm not sure if this has been discussed or suggested before but it would be
>> really nice to have a circular reference from IAtom back to it's parent
>> IAtomContainer. Working with other libraries that do provide this reference
>> (such as CML) makes it really intuitive when manipulating molecules. If you
>> have a method which matches two atoms (but requires the container to work
>> out certain properties) you can make the method a lot more readable and
>> generally reduce the number of times you need to pass a container and an
>> atom as arguments.
>>> match(IAtom query, IAtom subject)
>> instead of
>>> match(IAtomContainer query, IAtom queryAtom, IAtomContainer subject, IAtom
>> In my opinion it would also open up possibilities of making methods a lot
>> more usable (and OO). There's more then a few methods in IAtomContainer that
>> take an atom index or object as input which could be inverted to be members
>> of IAtom. Imagine be able to do this whilst iterating of atoms:
>>> atom.getConnectedAtoms() // bonds also
>>> atom.getConnectedAtomsCount() // bonds also
>>> atom.getBondOrderSum() // would actually work (currently it is a
>>> settable field)!
>> It should be relatively easy to do by adding an intercept when atoms are
>> added/removed to reference/un-reference a the parent container. I know from
>> past experiences that languages like Perl 5 mean you need to do a bit of
>> extra work (i.e. weaken(x) the references ) but in Java I'm not aware of any
>> such problems, the GC can definitely handle it.
>> Anyways, I would like to hear thoughts on this. I can whip up a quick patch
>> if needed to demonstrate.
>> Many thanks,
>> John May | Predoctoral Student – Chemoinformatics and Metabolism
>> European Bioinformatics Institute, Wellcome Trust Genome Campus, Hinxton,
>> Cambridge, CB10 1SD, UK
>> johnmay@... | +44–(0) 1223 49 2603
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> Cdk-devel mailing list