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
contracts.
2012/7/22, Ivanko B <ivankob4m...@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 <pascaldra...@googlemail.com>:
>> Am 22.07.2012 09:24 schrieb "Hans-Peter Diettrich"
>> <drdiettri...@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
>>
>
_______________________________________________
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
