Then "friend" classes as C++ offers and wait for this feature were implemented before proceeding with the optimization :)
2012/7/22, Giuliano Colla <[email protected]>: > 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 - [email protected] > http://lists.freepascal.org/mailman/listinfo/fpc-devel > _______________________________________________ fpc-devel maillist - [email protected] http://lists.freepascal.org/mailman/listinfo/fpc-devel
