[fpc-devel] RIP NoGlobals
Florian Klaempfl
florian at freepascal.org
Thu Sep 30 09:01:43 CEST 2010
Am 30.09.2010 02:38, schrieb 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,
True, not every type is a class in Object Pascal.
> and prevent the use of
> multiple back-ends in one binary.
... which has no use.
>
>>> - 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.
Yes, in an ideal world with endless resources.
>
>>> 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,
Indeed, currently people complain more about FPC's speed than about it's
stability.
>
>
>> 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 :-(
Really? Show me any *production* compiler which can be ported with a few
thousand lines of code to another architecture. The FPC backend is one
of the best written production compiler back ends I know.
> It's patchwork in many parts, that destabilized the legacy code.
Well, you didn't come up with clean fixes yet either :)
More information about the fpc-devel
mailing list