[fpc-devel] Opening FPC base classes

[michael.vancanneyt at wisa.be]

On Mon, 23 Jul 2012, Martin Schreiber wrote:

> On Monday 23 July 2012 13:58:56 michael.vancanneyt at wisa.be wrote:
>>
>> These fields must remain private to ensure proper functioning of the
>> component system. Too much depends on the proper functioning of the
>> notification API and the owner/owned relations and its inherent memory
>> management.
>>
> That is one of the reasons I need the full control. Please remember, the
> properties are "deprecated".

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.

If we need to make some adjustments in TFiler so it will treat additionally
other classes as it currently treats TComponent, we can do that as well.
This should not be hard to do. You probably only need 3 things:
- Decide (based on a class) whether to descend in a component or write a  reference.
- Set the name.
- Set the owner/parent.
These operations can be moved to virtual methods, and then the streaming can
stream a TComponent as well as a (supposed) TMSEComponent tree.

>
> [...]
>
>>> Is it possible to add
>>> "
>>>  protected //for toolkit access only
>>>   property HandlePrivate: THandle read FHandle
>>>                             write FHandle; deprecated;
>>> " to THandleStream
>>
>> No problems here. We can do this as well, provided we can make the
>> signature slightly different:
>>
>>
>>   protected
>>     Procedure SetHandle(AHandle : THandle); virtual;
>>     property HandlePrivate: THandle read SetHandle
>>
>> SetHandle will just set the FHandle fields, but I want a virtual setter
>> so descendent classes get a chance to react on the change in case they need
>> to.
>>
> Then SetHandle() is sufficient.

Fine.

>
>>> and
>>> "
>>>  protected //for toolkit access only
>>>   property CapacityPrivate: PtrInt read FCapacity
>>>                             write FCapacity; deprecated;
>>> " to TMemoryStream?
>>
>> TMemoryStream.Capacity is already read/write.
>>
>> Why do you think you need direct access to the field ?
>>
> "
>  TMemoryStream = class(TCustomMemoryStream)
>  private
>    FCapacity: PtrInt;
>    procedure SetCapacity(NewCapacity: PtrInt);
>  protected
>    function Realloc(var NewCapacity: PtrInt): Pointer; virtual;
>    property Capacity: PtrInt read FCapacity write SetCapacity;
>
> procedure TMemoryStream.SetCapacity(NewCapacity: PtrInt);
>
> begin
>  SetPointer (Realloc(NewCapacity),Fsize);
>  FCapacity:=NewCapacity;
> end;
>
> "
>
> The reason is to replace the memory without to trigger Realloc(). Used in the
> internal memory stream of tmsefilestream. tmsefilestream.create() behaves as
> memory stream, tmesefilestream('thefilename') as file so the descendants
> (ttextdatastream for example) can work with all the different stream kinds
> and inherit from TStream.

If it is internal to tmesefilestream, why don't you create your own descendent 
of TCustomMemoryStream ? If it is for this purpose, then it seems to be far
easier to use that technique than to request this change. There is nothing
magical about TMemoryStream.

Michael.