Re: [OpenBabel-Devel] Convenience functions

2017-03-06 Thread Stefano Forli
Hi Noel, I think I understand your idea, and it's totally compatible with the current design we're following. Indeed, the API is going to be for the atom. In fact, in the actual syntax of the datafile I sent before has an extra column (which I omitted) that specifies the element of the

Re: [OpenBabel-Devel] Convenience functions

2017-03-06 Thread Noel O'Boyle
The previous discussion was about having such a function in the public API. But anyway, let's say you do use smarts, you can still combine it with a switch statement on element and maybe on something else so that you don't end up testing the oxygen patterns against a nitrogen (this will already

Re: [OpenBabel-Devel] Convenience functions

2017-03-02 Thread Stefano Forli
Noel, I'm not sure how to describe all the cases with a switch statement. The original idea of using SMARTS came from your suggestion: > The thing is, if I was matching a functional group, I would just use a > SMARTS pattern. This is a general solution for 99% of cases, rather > than having a

Re: [OpenBabel-Devel] Convenience functions

2017-03-02 Thread Noel O'Boyle
The presence of a class or not is an "implementation detail", as they say. That is, the user doesn't need to know anything about that. However, as I am currently replacing the use of SMARTS patterns for atom typers with switch statements, I'd recommend you to avoid using SMARTS for this in the

Re: [OpenBabel-Devel] Convenience functions

2017-03-02 Thread Stefano Forli
Noel, thanks for the clarification, the only reason why I was looking at the lazy mechanism was because of previous code. I'm OK with the simple function, although I think there's still a need for a dedicated class behind which gets called to parse the different SMARTS patterns from a data

Re: [OpenBabel-Devel] Convenience functions

2017-03-02 Thread Noel O'Boyle
Typo: "But the guidelines are not unfortunately the existing code. " On 2 March 2017 at 10:22, Noel O'Boyle wrote: > Hi Stefano, > > Sounds good. But the guidelines are not unfortunately the existing > guide. I'm currently in the process of rewriting/removing as much of >

Re: [OpenBabel-Devel] Convenience functions

2017-03-02 Thread Noel O'Boyle
Hi Stefano, Sounds good. But the guidelines are not unfortunately the existing guide. I'm currently in the process of rewriting/removing as much of the croft as possible and the Lazy Evaluation mechanism is in my sights. It's a legacy from the original codebase. It'll be difficult to change this

Re: [OpenBabel-Devel] Convenience functions

2017-03-01 Thread Stefano Forli
Noel, quite the contrary, I'm far from being pissed at you, by all means. I like your suggestion, but I don't know if I can do it right away, there are still a few things about the facade programming paradigm that escape my hobbist programming training. Following up on the discussion about the

Re: [OpenBabel-Devel] Convenience functions

2017-02-25 Thread Geoffrey Hutchison
> About the PDB atom name, unfortunately I don't fully understand the > performance issue implied in my suggestion, but from an interface point of > view, it seems more intuitive to access an atom property from OBAtom instead > of going back to the OBResidue (and pass the OBAtom). The OBAtom

Re: [OpenBabel-Devel] Convenience functions

2017-02-25 Thread Stefano Forli
: [OpenBabel-Devel] Convenience functions Hi Noel, I agree with you and must say that in 99.99% of cases it's the right way to do. Although I still believe the convenient functions, especially the ones that loop over stuff, are extremely useful when called from Python - they are just so much

[OpenBabel-Devel] Convenience functions

2017-02-25 Thread Noel O'Boyle
Hi there, As some of you know, I would like to remove all convenience functions from classes in Open Babel. I would like to explain why. It's hard to exactly define a convenience function, but it's an addition to the API that is implemented entirely using existing API calls and that makes it