Re: [cclib-devel] Refactoring

[Noel O'B. <bao...@gm...>]

Sounds interesting. Anything that you feel makes it easier for people
to write parsers is ok with me. :-)

Just been reading today that instead of a massive switch statement
it's better to use a dictionary of functions. It's not exactly the
same, but it makes me think of something like...

for line in file:
    for keyphrase,blockname in keyphrases:
        if line.find(keyphrase)>=0:
             extract[blockname]()

e.g. keyphrase("Number of MOs") and corresponding blockname is 'MO section'

I'm not sure why you think it should return a tuple though (this makes
things more difficult). Surely it can just set the attributes from
instead the extract function.

Sounds like this is starting to turn into a major refactoring, and I'm
a bit wary of having this on the trunk, especially as it will be
experimental for the first while. Can you put this on a branch instead
and just test with a single parser for the moment?

On 02/02/07, Karol Langner <kar...@kn...> wrote:
> I have a more radical idea for refactoring the code for the parsers, which
> could structure them better and make them more 'standardized'. It still won't
> change anything in the user-side, but I really think something like this will
> give alot of long-term benifits in terms of writing new parsers and
> regulating common aspects (like LogFile.progress and attribute types).
>
> The attached file contains my fast scetch of the new parse function (so it
> probaly won't work).
>
> Besides parse() itself:
> 1) the extract methods of all parsers would be revised. This is pretty
> straightforward and I would do it with a script - the loop is cut out, and
> each conditional block  for line content needs to returns a tuple with the
> attributes that were set. If the "_" prefix were to denote private
> attributes, extract should probably be renamed to _extract at this point.
> 2) a few new dictionaries are needed for common information, as used in the
> attached file: _attrtypes (attribute types we want for each attribute),
> _fupdate (for the progress update), _msg (messages for progress). The last
> two should logically be attributes of the progress object itself), and could
> be set to default values by cclib if they don't exist (for compatibility).
>
> And that would be about it! If this all looks like it might work :) and you
> think it's a good idea, I'll go straight ahead and work on the details. I
> don't think it would take alot of work, and I have some spare time this
> weekend.
>
> Karol
>
> --
> written by Karol Langner
> Fri Feb  2 19:00:35 CET 2007
>
> -------------------------------------------------------------------------
> Using Tomcat but need to do more? Need to support web services, security?
> Get stuff done quickly with pre-integrated technology to make your job easier.
> Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
> _______________________________________________
> cclib-devel mailing list
> ccl...@li...
> https://lists.sourceforge.net/lists/listinfo/cclib-devel
>
>
>