[fpc-devel] Re: Class field reordering

[Ivanko B]

Then "friend" classes as C++ offers and wait for this feature were
implemented before proceeding with the optimization :)


2012/7/22, Giuliano Colla <giuliano.colla at fastwebnet.it>:
> 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
>
> _______________________________________________
> fpc-devel maillist  -  fpc-devel at lists.freepascal.org
> http://lists.freepascal.org/mailman/listinfo/fpc-devel
>