[fpc-devel] Re: Class field reordering

Ivanko B ivankob4mse2 at gmail.com
Sun Jul 22 13:29:17 CEST 2012

Some fields are kept private to ensure that the terms of the contract
can be met. Making them public/protected means that the terms of the
contract can be broken by Developer A, when the code of developer B
depends on the terms being rigorously enforced, and his code can go
very wrong.
Then additional protected properties exposing private fields can also
be a part of these contracts - as a agreed exclusions to the

2012/7/22, Ivanko B <ivankob4mse2 at gmail.com>:
> 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

More information about the fpc-devel mailing list