[Opencxx-users] opencxx refactoring

[Stefan S. <se...@sy...>]

hi there,

as I have been getting into the opencxx internals over the last weeks,
I'v started to refactor / redesign the code. Here are some thoughts
about this efford.

I renamed some classes to make their goal clearer, and I changed the
method names to be more consistent with the rest of synopsis' naming
conventions. Anyways, here is the meat:

* reduce unnecessary abstraction:
   The 'Program' classes are gone and replaced by a single 'Buffer'
   class, which holds the data the ptree is constructed on top of.
   If you want to read from file, string, or console, just use the
   appropriate streambuf type and pass that to the Buffer's constructor.

* rewrite the Lexer:
   enhance Token and Lexer classes. In particular, consider the Buffer data
   const, i.e. make all methods take 'const char *' instead of 'char *'.
   Simplify the Lexer code to use std::map and std::queue instead of
   its own types. The performance penalty is tolerable (< 10%).
   The benefit is that individual keywords can be added/removed at runtime,
   which allows for 'cross-compilation' as well as support for C++ as well as C.

* clean up the parse tree types:
   Some type renaming aside, I cleaned up the 'PTree::Node' (former 'Ptree') interface
   substantially:
   I introduced a generic 'Visitor' class and added 'accept' methods to all
   ptree node types. I then reimplemented the 'display' and 'write' methods
   by Visitor subclasses. I did the same for the 'type_of' and 'translate'
   methods, so now PTree nodes don't know about neither TypeInfo nor Walker
   any more. (Phew !!)
   Finally, I cleaned up the Encoding class such that PTree::Nodes now hold
   PTree::Encoding instances instead of 'char *'.

That's about where I am right now. The PTree namespace looks quite clean
already. One issue I'm not quite satisfied with is the design of Encoding
and TypeInfo (and Environment, just to name all classes that touch this
design): I'd like to get back to this in the not-so-far future.
Next comes the 'Environment' class. As I said in my last mail, that looks
a bit monolithic, i.e. instead of putting specific cases into subclasses
(class scope with lookup in base classes, to name one example), it's all
contained in this single class.

Once these points are addressed, I believe it would be a good time to
start thinking about the Parser and how the symbol lookup could be
integrated right into the parse stage (instead of doing a second pass
over the ptree via ClassWalker).

What do you think about these changes ? Whether we decide to work on the
parser or keep it as it is, I believe the changes I have applied already
provide an important cleanup of the design, and thus make it much more
easy to maintain and extend the existing functionality.

Comments are highly appreciated,
		Stefan