Hi, On 22 July 2012 07:14, Ivanko B <ivankob4m...@gmail.com> wrote: > private > prorerty Private1: integer read fldPrivate1 write fldPrivate1; > prorerty Private2: integer read fldPrivate2 write fldPrivate2; > protected > prorerty Private1relaxed: integer read fldPrivate1 write fldPrivate1; > > Then MSEgui/FPgui may rely on Private1relaxed insted of fldPrivate1+cracker.
I'm sorry Ivanko, but that defeats the whole point of well designed classes and hierarchy. As Michael mentioned - if good reason can be given why a specific private field needs to be accessed, then sure, it should be moved to protected or some property added. The FPC team was accommodating with me in this regard in the past, so I can't see why they would treat Martin any different. Martin simply needs to take them case by case - instead of littering his framework with "cracker" classes, and never raising the issues with the FPC team. Yes, now it is more work for Martin [having having many "cracker" classes implemented], but he should have spoken sooner. -- Regards, - Graeme - _______________________________________________ fpGUI - a cross-platform Free Pascal GUI toolkit http://fpgui.sourceforge.net _______________________________________________ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
