On Sunday 13 August 2006 13.27, Marco van de Voort wrote: > > It is ugly, produces warnings and is possibly forbidden in FPC 2.1.1 (I > > don't know). A more elegant solution would be to have something like > > 'friend units' where protected class members are visible: > > I wonder what the use of making a private/public/protected distinction is > in the first place, if USES'ing units can override it at will. >
In a tool library: public -> interface for the library users, use it without knowledge of the internals. protected -> interface for the library developers, use it if you know what you do. Use strict protected if you want to secure encapsulate things. private -> secure encapsulated class items. Note that I had to use 'cracker classes' in MSEgui to access private FPC class items to implement workarounds... I must repeat: It is not possible to develop a complex system in a clean single class hierarchy, especially not if you use foreign units which are not under your control . I know it because I tried it... Martin _______________________________________________ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
