Michael Banck wrote:
> On Sun, Sep 11, 2005 at 02:19:56PM -0400, Geoffrey Hutchison wrote:
>>Right now, in the development code, the OBSmilesParser class and
>>related classes are in the smilesformat.cpp file. While this
>>decreases the size of the main library, it also means that any
>>program using libopenbabel can't easily access the SMILES parser
>>directly. In order to parse a SMILES string in memory, the program
>>has to invoke the OBConversion.
>>I'd like to move the SMILES parsing code back into parsmi.cpp for
>>external programs (e.g., this is a SMILES string from user input).
> Making it available to anybody without gratuitious conversions seems the
> right approach, short of a plugin/module system...
> The other possibility would be to break out certains parts (which?) into
> their own libraries and expect developers to pick what they need.
If the API library was being used without any I/O except SMILES
input it would be necessary to move the parser back to the API,
and I don't see any difficulties doing it. Moving the code that
writes SMILES would be a little more difficult since it has some
output options, some which would have to be passed as function
But would most users not have some I/O? (Except perhaps those
unfortunates using Cygwin.)
The current code to convert a std::string SmilesString to an OBMol
if(conv.SetInFormat("smi") && conv.Read(&mol))
The revised code would be shorter, but not by much:
The current longer version could be made into a little global
inline function in obconversion.h to make it easier to remember.
The code that's executed in both versions is almost the same - the
format version just checks for a name after the string.
The argument for keeping the SMILES code in a format is that it
maintains segregation of function, with all the I/O in formats. In
the future maybe it would be considered appropriate to also move
InChI generation into the API...? There is a little bit of a down
side in compromising the programs structure to set against any