[fpc-other] Fork

[Hans-Peter Diettrich]

Florian Klämpfl schrieb:

>> 1) In the fpc-devel I have read quite a few arguments that FPC is
>> production quality and no significant changes can be afforded to that code.
>>
>> While I sympathize with what that implies, it also means that,
>> structurally, FPC is more or less frozen 
> 
> This is wrong. If a big change promises significant advantages for FPC
> users, it will be done. Things like turning the parser upside down
> simply don't have an significant advantage for users.

Well, I doubt that the *want* for such advantages can be followed by the 
required updates. As it already turned out, most refactoring will result 
in consequential changes to a huge number of units, whose integration 
has been rejected for each of my refactoring attempts. It also may be 
unclear *which* parts of the fork have to be imported, when the achieved 
advantage depends on other changes. Of course there exist chances for 
some strictly local changes (micro optimizations), but most likely I 
won't separate such changes into specific commits, when I come across 
them while working on an different issue.

But perhaps we then can turn things upside down, and I'll spend some 
time to prepare certain parts for FPC trunk integration. Then it's up to 
the FPC maintainers to resolve those issues themselves, that lead to the 
rejection of my patches before (coding style...).

DoDi