[fpc-devel] OO rewrite - globals

[Florian Klaempfl]

Am 26.07.2010 02:22, schrieb Hans-Peter Diettrich:
> 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? 

Well, with the same argument one could stuff all code in one source file
and don't separate anything in units.

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.

> 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 simply don't like the idea of having one big parser class blob spread
over multiple include files.

> 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 at lists.freepascal.org
> http://lists.freepascal.org/mailman/listinfo/fpc-devel
>