[fpc-devel] OO rewrite - globals

Hans-Peter Diettrich DrDiettrich1 at aol.com
Sun Jul 25 12:05:03 CEST 2010

In the meantime I could make the OO compiler compile, but it does not 
already work (project ppoo.lpi). Can somebody assist in the separation 
of the many global variables, which have to become fields in distinct 
classes (tmodule, tparser...)?

The intended data tree looks like this:

MainModule: T[Main]Module; //can hold the list of all modules
   Module: TModule; //current_module, in module list
     Parser: TParser; //current_scanner (includes scanner)
       ProcInfo: TProcInfo; //current_procinfo

*can* hold application-wide settings, but these can remain in global 
variables (and different units) as well.

holds all module specific settings and objects. The Parser (and other 
objects) only exist during parsing and code generation, can be destroyed 
(or re-used?) when done.
It looks to me as if a ppu reader can provide the information for 
previously compiled modules, so that a scanner/parser is not always 
required to load a used module?

now is derived from the tscannerfile class. This allows to use different 
parsers (front-ends). For that purpose Compile() has become a class 
method, that can check the file extension or content, and can create an 
specific parser accordingly. The same could be done for the selection of 
the target (machine/system) specific back-end.

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.

All the current_xyz variables must become class elements. Who knows 
about the scope and lifetime of these "current" objects, and can give 
hints where to move these references?

In InitCompiler, InitParser and InitScanner a bunch of objects are 
created, that should be assigned to the appropriate level (object) in 
the data tree.

See the $IFDEF NoGlobals sections, which enclose the already identified 
declarations and initializations, that have to be refactored. 
Unfortunately I already changed parts of that code, so that the original 
code will have to be reconstructed, in order to make the compiler work 
again (using global variables).


More information about the fpc-devel mailing list