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
_______________________________________________
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
