[fpc-devel] Opening FPC base classes

Ivanko B ivankob4mse2 at gmail.com
Mon Jul 23 17:57:59 CEST 2012


 These fields are private for a reason.
 Making them protected exposes them e.g. in TForm and TDatamodule from
 Lazarus, which is a can of worms we are not going to open.
====================================
Such (exposing private fields to the protected level) properties may
have special names which can be filtered out.
Guys, please take into consideration not only Martin but also Graeme,.. :)


2012/7/23, Martin Schreiber <mse00000 at gmail.com>:
> On Monday 23 July 2012 15:31:42 michael.vancanneyt at wisa.be wrote:
>>
>> You ask to throw away the very purpose and reason of existence for
>> TComponent. This is not going to happen.
>>
>> The 'deprecated' does not change that. These fields are private for a
>> reason. Making them protected exposes them e.g. in TForm and TDatamodule
>> from Lazarus, which is a can of worms we are not going to open.
>>
>> Please explain the actual problem. Till now you explain your solution to
>> a
>> problem you seem to have, not the problem itself. You hide behind other
>> 'potential' problems.
>>
>> And in general:
>> if TComponent imposes such restrictions on what you want to do: Simply do
>> not use it. There is nothing sacred about TComponent. Lazarus for
>> instance
>> only requires TPersistent.
>>
>> This is not as bad or such a big obstacle as it may seem: The tiOPF
>> framework has written a complete class system without referring to
>> TPersistent or TComponent, it uses RTII successfully.
>> It works very well, I use it myself.
>>
>> I don't see why you cannot do the same. It's perfectly possible to use
>> the
>> streaming system for both TComponent and other classes. All it takes is
>> RTTI, which happens to be enabled in TPersistent.
>>
> Because of integration of third party components. But you are probably
> right,
> it seems to be the time to leave FCL compatibility. The design of
> TPersistent/TComponent and the whole classes unit has been made by Borland
> so
> that it made the development of a concurrent IDE to Delphi as difficult as
> possible. I hope Free Pascal has not the same attitude. ;-)
>
> Thank you again for your time,
>
> Martin
> _______________________________________________
> fpc-devel maillist  -  fpc-devel at lists.freepascal.org
> http://lists.freepascal.org/mailman/listinfo/fpc-devel
>



More information about the fpc-devel mailing list