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