[fpc-devel] Re: Class field reordering

[Ivanko B]

the users must compile the RTL for non Lazarus use.
=============
Really , it needs  FPC sources at user's side.

Then  a workaround - to maintain protected properties for private variables :

private
 fldPrivate1: integer;
 fldPrivate2: string;
[..]
private
  prorerty Private1: integer read fldPrivate1 write fldPrivate1;
  prorerty Private2: integer read fldPrivate2 write fldPrivate2;
protected
  prorerty Private1relaxed: integer read fldPrivate1 write fldPrivate1;

Then MSEgui/FPgui may rely on Private1relaxed insted of fldPrivate1+cracker.

Once a cracker disabled, all related fldPrivate(N) needing replacement
with Private(N)relaxed will be revealed at 1-st compilation.


2012/7/22, Martin Schreiber <mse00000 at gmail.com>:
> On Saturday 21 July 2012 23:57:50 Florian Klämpfl wrote:
>> Am 21.07.2012 23:06, schrieb Ivanko B:
>> > No, just reorder the fields so that they can be properly $IFDEFed as
>> > protected for nonLAZARUS and left (private) as is otherwise.
>>
>> Why should lazarus people have less chances to mess with private fields?
>> Either we make them public for all or for nobody. Of course, then
>> everybody has to take care of the fact that users might mess with these
>> fields.
>>
> As I wrote earlier:
> "
>  Suggestion:
> For all FCL base classes which are used in different toolkits and which
> can't
> be forked without breaking precompiled third party components, namely the
> units classes and db, move *all* private fields and methods to protected and
>
> mark them as "Use on your own risk, can be changed everytime! Don't cry
> afterwards.".
> "
> The {$ifdef} IvankoB suggests is not ideal because it either needs different
>
> precompiled RTL's or the users must compile the RTL for non Lazarus use.
>
> Martin
> _______________________________________________
> fpc-devel maillist  -  fpc-devel at lists.freepascal.org
> http://lists.freepascal.org/mailman/listinfo/fpc-devel
>