On Mon, 14 Aug 2006, Martin Schreiber wrote:
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...
No. It just means the classes are designed wrong.
If you need to access directly private class fields, I think there are serious
design flaws in your code.
Michael.
_______________________________________________
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
