[fpc-devel] RIP NoGlobals
DrDiettrich1 at aol.com
Thu Sep 30 02:38:43 CEST 2010
Florian Klämpfl schrieb:
>> In the past months I've been working on several aspects of such
>> - moving global variables into objects (mainly current_module)
>> - turning back-ends into classes
> The fpc back end is completly OOP?
To some degree. Basic data types are hard coded, and prevent the use of
multiple back-ends in one binary.
>> - separation of parser (front-end) from AST processing (building AST,
>> optimization, code generation)
> I fear that this will make the code even more fragile because the code
> gets spread among more locations.
It's a matter of the related interfaces/APIs.
>> When we agree to turn the current codebase into such an OO approach,
>> eventually adding documentation, the maintenance could be simplified a
> We had for 1.0 a rather complete documentation. However, it outdated too
> quick and it didn't simplify maintainance in any way.
That's because the implementation didn't follow the documentation. A
strict OO design can be implemented according to the documentation.
>> During my experiments I've learned how fragile the current state of
>> the compiler codebase is - even a minor change can have inpredictable
>> consequences in other parts of the code.
> This won't change. A compiler is simply something very interwinded. Your
> problems with cyclic unit dependencies prove it.
These problems only prove poor coding conventions. When speed is favored
over stability and flexibility, such code is principally hard to
>> Chasing and fixing an bug would
>> be much easier, when it can be isolated in a specific compiler module,
>> and then can be fixed with only local impact.
> Nice dream, but that's exactly the problem of the harder bugs: they
> cause conditions not forseen by the original writer of the code.
Such situations can be reduced by more high-level interfaces, that don't
leave much room for unsupported or illegal states of the related objects.
> While I agree that we should refactor parts of the compiler, it should
> be done in an evolutionary way. Don't forget, work on 2.0 took 6 years.
And the results of that work are not really pleasing :-(
It's patchwork in many parts, that destabilized the legacy code.
More information about the fpc-devel