From: <se...@in...> - 2004-08-31 16:03:15
|
On Tue, 2004-08-31 at 02:10, Stefan Seefeld wrote: > 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: [...] > 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, Templates make a C++ parser at least 'x' times harder. Can you explain how we can handle template specialization with current parser. What I understand, - specializing templates requires that the tokens for a template declaration be saved so that the template can be reprocessed when the actual template arguments are specified. - it requires the syntax phase to perform near-complete type, scope, and expression analysis, including function overloading. Present design predate such change to the language. In my vocabulary, present design is "C-Front style". So my believed is that we need to rejuvenate the design. But my question is how. > 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. |