[fpc-devel] RIP NoGlobals

[Hans-Peter Diettrich]

Florian Klämpfl schrieb:

>> In the past months I've been working on several aspects of such
>> refactoring:
>> - 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
>> lot. 
> 
> 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 
maintain :-(


>> 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.

DoDi