Am 26.07.2010 12:32, schrieb Hans-Peter Diettrich: > Florian Klaempfl schrieb: > >>> When a parser is designed to work with exactly one scanner, why should >>> it not inherit from it? >> >> Well, with the same argument one could stuff all code in one source file >> and don't separate anything in units. > > Encapsulation requires some separation.
Yes, see below ;) > >> Having parser and scanner separated might also enable more fine grained >> multi threading later one: the scanner creates fills a token queue which >> is read by the parser later on, I know this won't be easy because FPC's >> scanner is parser context sensitive. > > At least the scanner "context" is used in many places in other code. A > hypothetical token stream had to include the full scanner context, i.e. > file/offset/line/column information, as well as current_settings, for > *every single* token. Not very practical :-( The current_settings can be reused using ref. counting. > > >> 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 ? _______________________________________________ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel