[fpc-devel] RIP NoGlobals

[Florian Klämpfl]

Am 29.09.2010 22:05, schrieb Hans-Peter Diettrich:
> Florian Klämpfl schrieb:
> 
>>> too much supported platforms and
>>> features and too few developers working on bug fixing.
>>
>> Just as a side node, development of open bugs during the last years:
>> summary_graph_cumulative_bydate.php.png
> 
> This situation could be improved by an OO rewrite - better
> modularization, separation and encapsulation of the entire compiler parts.
> 
> 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?

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

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

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

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

> Visual debug features (AST
> treeview, ASM preview...) 

printnode(node);

> can be added without affecting the release
> versions - such features already turned out to be very useful, in all my
> decompiler development.
> 
>
> Since such refactoring affects really *all* existing units, it could be
> done in a very new repository, resulting in an FPC 3.0 version. Then we
> can agree which road to follow - the old spaghetti code or the new OO
> approach - or whether we fork and follow both branches independently.
>

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.