[fpc-devel] NoGlobals branch
Hans-Peter Diettrich
DrDiettrich1 at aol.com
Wed Aug 18 12:34:38 CEST 2010
The removal of global variables is almost finished now. I know that the
code currently doesn't look nice, and that performance can be improved,
but these are minor details compared to the attempts to not break the
compiler itself.
In the last round a GlobalModule has been added, that plays the role of
a not yet existing current_module at compiler initialization. Since the
remaining global variables currently are scattered across many units,
they could be moved all into the GlobalModule - any opinions?
For performance reasons it were nice to have unit-level properties with
variable refences for the getters, instead of subroutines - any reasons
why this is not allowed right now?
What should be done in the next step?
In contrast to the preceding OO approach, a bunch of ordinary procedures
still waits for becoming methods, with faster access to frequently used
class members. Should I try to convert the procedures to methods now, or
should I wait until everything else has settled down?
Another task were the separation of the implementation parse and code
generation, from interface parsing. This separation would allow for
multiple worker threads for e.g. code generation.
Any suggestions?
DoDi
More information about the fpc-devel
mailing list