Florian Klaempfl schrieb:
I simply don't like the idea of having one big parser class blob spread
over multiple include files.
I don't like it as well :-(
But what is the reason against a
TModuleParser
TDeclarationParser
TSubroutineParser
TStatementParser
TExprParser
?
How are these objects created, and how shall they communicate? (where
should their references be stored? Even more global variables, for
access to each current_xyzparser and his (local) objects?
Every sub-parser will have to reference (create and use) all the other
parser types, so that a bunch of temporary parser objects will have to
be created and destroyed frequently. Or according references to reusable
objects must either go into the parser class (preventing unit references
back to the parser unit), or they have to be passed along as subroutine
arguments - one argument for each sub-parser.
It would be acceptable to have data container objects for the parsed
declarations, subroutines etc., when these objects are put into their
own hierarchy (like already done for the nodes), so that the code
generation dependencies can be removed entirely from the parser.
DoDi
_______________________________________________
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
