Florian Klämpfl schrieb:
Parser
now is derived from the tscannerfile class.
This is a really ugly design OOP wise ...
When a parser is designed to work with exactly one scanner, why should
it not inherit from it? In the first approach I added delegates for
scanner methods to the parser, but since this only adds another level of
indirection, it has been almost dropped from later versions.
Most parser units have been split into .pas and .inc files. The .pas
files mostly contain declarations, that can not be moved into the parser
unit without causing circular unit references.
Why don't you use separate parser classes for different purposes?
Declarations, Function bodies, expressions etc.?
For performance and management reasons, and to prevent cyclic unit
references. I see no real need for subdividing a grammar into multiple
(arbitrary) parts. In a future version many syntactical methods can
become local subroutines, so that they disappear from the methods. The
suggested separation is much more meaningful for the semantical code,
i.e. translation into internal data structures etc., up to the final
code generation.
IOW I see no need to replace CONSUME(whatever) by e.g.
{self.}base_parser.current_scanner.CONSUME(whatever).
DoDi
_______________________________________________
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
