Quantcast

[Open Babel] Re: Moving OBSmilesParser out of smilesformat.cpp

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

[Open Babel] Re: Moving OBSmilesParser out of smilesformat.cpp

Geoffrey Hutchison

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).

Any concerns?
-Geoff


-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
_______________________________________________
OpenBabel-discuss mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/openbabel-discuss
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [Open Babel] Re: Moving OBSmilesParser out of smilesformat.cpp

Michael Banck
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.


Michael

--
Michael Banck
Debian Developer
[hidden email]
http://www.advogato.org/person/mbanck/diary.html


-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
_______________________________________________
OpenBabel-discuss mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/openbabel-discuss
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [Open Babel] Re: Moving OBSmilesParser out of smilesformat.cpp

Chris Morley-3


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
parameters.

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
mol is:

    OBConversion conv(&stringstream(SmilesString));
    if(conv.SetInFormat("smi") && conv.Read(&mol))
      ...

The revised code would be shorter, but not by much:

    OBSmilesParser sp;
    if(sp.SmiToMol(mol,SmilesString))
      ...

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
potential benefit.

Chris



-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
_______________________________________________
OpenBabel-discuss mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/openbabel-discuss
Loading...