On Thursday 19 July 2012 05:13:01 Luiz Americo Pereira Camara wrote: > I also have somethings in fpc rtl/fcl that also don't like or changing > would simplify my work. But if we start to change base classes at each > developer request we may end with a mess. > Just to be clear, i'm not against all changes. Some specific points can > be changed at careful examination (like devs are already doing) > I don't think moving fields from private to protected in order it is possible to implement the wanted behaviour in my library need careful examination because it does not touch the FPC functionality.
I *never* asked to change *any* functionality in FPC-RTL other than to fix bugs which could be demonstrated by a different behaviour to Delphi 7! And I had no problems to use cracker classes and mad workarounds on my own risk in order not to bother the FPC team with my needs. The problem now is that cracker classes can't be used in future anymore because of the new class field ordering optimisation, so I dared to ask. > BTW: some time ago you pointed in a fpc list that will not use trunk > because of encoding aware strings, so you don't need to worry because > the trunk changes won't affect you anyway > At the moment. I hope sometimes in the future the FPC team can say "the dust has settled down now and the Unicode handling in FPC is/will be done so and so". I do not want to adapt MSEgui to a moving target. BTW: does anybody know how unicode resourcestrings work or are planned to work in FPC trunk? Martin _______________________________________________ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
