[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
...
MainModule
*can* hold application-wide settings, but these can remain in global
variables (and different units) as well.
Module
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?
Parser
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).
DoDi
More information about the fpc-devel
mailing list