Michael Van Canneyt schrieb:
The base classes expose a well-defined API. This API is a contract you make with the developers of descendent classes.
Which you don't know when designing a base class.
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.
IMO there exist two use cases for (base) classes: by end users and by component writers. Both have different goals and problems, which rarely can be covered by an single set of properties. When an end-user never should be allowed to write into some field, a developer may have reasons to do so.
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.
The more I think about these problems, the more I see class helpers as the natural extension of the language, that allows to implement extensions which have not been foreseen by the class designers. At the risk of the implementors and users, of course.
And, if possible, alternative solutions will be presented if they can be found. But for that, I need to know in detail what the problem is in the first place.
See above. DoDi _______________________________________________ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel