Re: [Open Babel] Suggested modified conversion framework

[Geoff H. <ghu...@ws...>]

Coming back to this again...

On Jan 4, 2004, at 10:09 AM, Chris Morley wrote:

> - A clearer separation of functions - the  chemistry needs to be more
> separated from the conversion. (e.g. OBMol should not be where the
> input and output file formats are stored). The FileFormat class could
> be beefed up to do this.

Agreed. I may have missed it--did you post code for your changes?

One enhancement you don't talk about in the pages is access to an OBMol 
or OBMolVector or whatever from the OBConvert class. Let's say I'm 
developing a modeling package and use OB for importing other file 
formats. I'd like to grab the OBMol result (or whatever) and act on it 
rather than going directly to an output stream.

> - Each format  needs to be self contained. A new format should not
> require any changes  in old code. (This is what abstract base classes
> are for.)
...
> - The input and output routines need to be more aware of the conversion
> process so that they can adjust. Examples are the previously discussed
> need deal on-the-fly with generated molecules during CML input, and
> the need for a conditional <cml>...</cml> wrapper during output.

I think this is critical to handling 2D/3D coordinate issues as well. 
The file format code should offer a class that provides information to 
the conversion format. This would enable OBMol to know if it "came" 
from a 2D or 3D (or 0D in the case of SMILES) format. Does it have 
multiple coordinate sets? etc.

> molecule, sets of molecules(conformers?), reactions, sets of 
> reactions, etc.

Right now, the scheme is that conformers should be handled inside 
OBMol. Is this how we'd really like to do it? I think probably 
yes--conformers are different sets of coordinates, but *not* different 
sets of atoms, bonds, etc.

So the distinction I'd draw is this:
* isomers, etc. -- different OBMol
* conformers, 2D/3D coordinate representations -- same OBMol, multiple 
coordinate sets

-Geoff