Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Patch/apicleanup2 #309

Merged
merged 14 commits into from May 2, 2017
Merged

Patch/apicleanup2 #309

merged 14 commits into from May 2, 2017

Conversation

johnmay
Copy link
Member

@johnmay johnmay commented Apr 28, 2017

Clean up two, I've left the n-centre bonds as they are (for now) but added utility methods for bond.getAtom(0) and bond.getAtom(1). These can now be called with bond.getBeg() and bond.getEnd(). Also ```getConnectedAtom(IAtom)is now the shortergetOther(IAtom)``. The existing methods are still there so no API breakage.

The first one is shortened to line up nicely.

IAtom beg = bond.getBeg();
IAtom end = bond.getEnd();
IBond nbr = bond.getOther(beg); // nbr == end

The terms begin/first, and end/second are widely used, not only do they provide cleaner code but they should lower the barrier to entry from other toolkits. Here is a quick survey of other toolkits.

OEChem: bond.GetBgn() and bond.GetEnd() bond.GetNbr()
RDKit getBeginAtom() getEndAtom() getOtherAtom()
OpenBabel bond.GetBeginAtom() bond.GetEndAtom() bond.GetNbrAtom()
ChemAxon: bond.getAtom1() bond.getAtom2() bond.getOtherAtom()

@egonw
Copy link
Member

egonw commented Apr 30, 2017

Can you please rebase?

@egonw
Copy link
Member

egonw commented Apr 30, 2017

(Also: is this to be put in before the paper resubmission?)

@johnmay
Copy link
Member Author

johnmay commented Apr 30, 2017

No need before resubmission but before 2.0 release

@johnmay
Copy link
Member Author

johnmay commented May 1, 2017

Rebased

@egonw
Copy link
Member

egonw commented May 1, 2017

Not sure about the method name getBeg()... I'm personally not in favor of this... getBegin(), getStart() is only marginally longer... I fully support this as short cut for getAtom(0)... no matter what the name is, it nicely reflects the assumption of a two-atom bond...

@johnmay
Copy link
Member Author

johnmay commented May 1, 2017

I'm okay with getBegin()... OEChem's getBgn() is horrible maybe we ask the mailing list. The reason I used getBeg() it because

IAtom beg = bond.getBeg();
IAtom end = bond.getEnd();

looks marginally nicer than

IAtom beg = bond.getBegin();
IAtom end = bond.getEnd();

@johnmay
Copy link
Member Author

johnmay commented May 1, 2017

I may also add a setBegin/setEnd but actually a water-tight API would say you must create a new bond rather than modifying the end points. In all cases I looked at bond.setAtom() is only used before a bond is added to an IAtomContainer hence it may as well be immutable... of course the current API doesn't allow that.

@johnmay
Copy link
Member Author

johnmay commented May 2, 2017

rebased

@egonw egonw merged commit 20e33fb into master May 2, 2017
@johnmay
Copy link
Member Author

johnmay commented May 2, 2017

Awesome and thanks - I'm going to do a CDK 1.5.15 release ahead of 2.0. I've almost got the fast AtomContianer impl working but there will be some breakages if the API is currently being miss-used. Essentially the atom/bond you put into the AtomContainer isn't the one you get back, you get back a wrapped reference (which can choose to unbox). Any unchecked casts to non CDK interfaces (IAtom, IPseudoAtom, IQueryAtom) will now fail, the only place this was a problem in the tests was the pcore matching.

If the API is being used safely (no unchecked casts or reference equality) then the new API will work fine but to be portable I'll do a 1.5.15 that will allow Bioclipse/AMBIT the upgrades with no unexpected behaviour.

@johnmay johnmay deleted the patch/apicleanup2 branch June 17, 2017 10:14
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants