[fpc-devel] Re: Class field reordering

[Giuliano Colla]

Il 22/07/2012 10:39, Michael Van Canneyt ha scritto:
>
>
> On Sat, 21 Jul 2012, 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.
>
> Which is exactly why we will not do this.
>
> The base classes expose a well-defined API. This API is a contract you 
> make with the developers of descendent classes.
>
> 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.
>
> This is of course not so for all private fields, which is why I ask 
> for reasons, so I can decide for each field what can or cannot be done.
>
There are excellent reasons not to expose private fields. What must be 
opaque and what must be visible to end users are designers decisions 
which involve the capability of providing new implementation without 
breaking existing code, take into account multiplatform needs, consider 
the planned improvements, etc. etc.

On the other side there are sometimes good and sound reasons for someone 
to break this rule, at his own risk, of course. It may be to quickly fix 
a bug, to provide an extra feature by reusing an existing object instead 
of rewriting a lot of code, etc. Of course this is a practice not to be 
recommended in general, but it occurs. And in many cases it is connected 
to specific needs which aren't of general interest, making the effort of 
supporting them hardly worthwhile.

IMHO a clean solution can be found at language level: if I declare

TMyclass = class(TWhatever)

then I just get the degree of visibility that the class designer has 
decided.

But if I declare (just an example, a better keyword can be found)
TMyclass = subclass(TWhatever)
then I get full visibility, all the private fields of TWhatever become 
just protected in TMyclass, and of course, I'm on my own. The designer 
is not bound to any contract, because I have explicitly decided to run 
the risk.

This solution would allow mainstream designers to keep fields visibility 
to what they deem to be a safe level in general, without making it 
impossible to non mainstream designers to provide features which aren't 
considered of general interest.

Just my 5 cents.

Giuliano