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