[fpc-devel] Re: Class field reordering

Hans-Peter Diettrich DrDiettrich1 at aol.com
Sun Jul 22 15:22:44 CEST 2012


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





More information about the fpc-devel mailing list