[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