[fpc-devel] Re: Class field reordering

[Ivanko B]

A (global) compiler option "treat private as protected" might be
another solution.
============
Same and less flexible than the {$ifdef nonLazarus} solution.

What are the numbers of the issues worked around by the crackers?
===============
The exact number isn't very important. For instance, Martin, Graeme...
always report all bugs found by them but still need the ability to
proceed without waiting for the bugs gets fixed [ sometimes because
guys like me & customers insist on it].
Forking is bad since squeezes the base of advanced users (bug reveals,
good proposals & patches, ..) of the forked feature of mainstream
project.


2012/7/22, Sven Barth <pascaldragon at googlemail.com>:
> Am 22.07.2012 09:24 schrieb "Hans-Peter Diettrich" <DrDiettrich1 at aol.com>:
>>
>> Martin schrieb:
>>
>>> On 21/07/2012 16:55, Ivanko B wrote:
>>>>
>>>> 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.
>>>
>>> ....
>>>>
>>>> So, is it possible to design the new feature in such way that to have
>>>> an option to proceed using cracker classes ?
>>>>
>>>
>>> But the whole discussion comes down to one other simple question.
> Including the above, the whole discussion is about:
>>>
>>>    Should FPC provide a way to access private fields from any other
>>> code?
>>
>>
>> Like recent Delphi versions allow by extended RTTI? <shudder>
>>
>
> FPC will support extended RTTI sooner or later as well.
>
>> Finally class helpers could solve the problem as well, the cleanest
> solution IMO.
>
> While they would be the cleanest solution they won't work as they can only
> go as deep as (strict) protected (which I still not think was a good by
> Borland as public/published should have been enough...)
>
> Regards,
> Sven
>