[fpc-devel] Class field reordering

[Martin Schreiber]

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