[fpc-devel] Class field reordering

[michael.vancanneyt at wisa.be]

On Wed, 18 Jul 2012, Martin Schreiber wrote:

> On Tuesday 17 July 2012 09:40:36 michael.vancanneyt at wisa.be wrote:
>>> Maybe, but what about performance? Another complication is the
>>> "updatebuffer" with the "oldvalues".
>>
>> Thinking about it:
>>
>> I would allocate the buffer as is, with for all string fields an
>> integer-sized slot in the buffer. The slot contains an index, pointing
>> to a separate array of strings containing  N*M*2 strings. (N=number of
>> records, M= Number of string fields per record, factor 2 for old values)
>>
>> Field value =  Element [Index  [+1 for old value]] in the array.
>> where the [Index] is stored in the buffer.
>>
>> The speed performance penalty of this system should be negligable, since
>> you assume all records are in memory anyway.
>>
>> And: everything can be done without meddling with the internals of TField.
>>
> Thank you. There are more items in the db.pas list...
> But I think first we should concentrate on classes.pas because I really don't
> want to fork it. Forking db.pas is less problematic and I probably prefer it
> in place of an endless discussion and in my eyes not optimal solutions. With
> a forked db.pas I can eliminate the many workarounds I already had to
> implement.
>
>
> Currently needed crackerclasses by MSEide+MSEgui:
>
> Used by MSEide for different tasks (example: ask for ancestor forms and
> frames/submodules while loading a form/datamodule, recover in case of an
> error) and for streaming of frames with additional components/widgets:
>
> TComponent:
> - FComponents
> - FComponentState
> - FFreeNotifies

Descendent classes should not manipulate these except through the right
methods such as insert/remove component and FreeNotification/RemoveFreeNotification ? 
You have the means to manipulate the contents, what is wrong ?

>
> TWriter:
> - FPropPath
> - FAncestors

I see no problem in making these available as read-only protected
properties.

>
> TReader:
> - FStream
> - FLoaded
>
> Used in order TParams create tmseparam items instead of TParam:
>
> TCollection:
> - FItemClass

A collection must always contain the same items. The class is determined
when the collection is instantiated.

>
> Used to unify memorystreams/files/pipes/sockets/stringstreams:
>
> THandlestream:
> - FHandle

The handle is fixed throughout the lifetime of the stream. It is set when
creating the stream, and closed when destroying the stream.

>
> TMemoryStream:
> - FCapacity
>

What is wrong with the r/w property "Capacity" ?

I think you are missing an important point:

You want some radical changes, so I expect you to be the one giving the 
reasons/motivations for a change. I want to help find solutions, but not
at the price of destroying what is in my eyes a correctly constructed class 
hierarchy.

If you don't give a detailed explanation why you need to manipulate 
all these private fields outside of the proper methods, then I cannot 
help you find solutions for the problems you experience, so please:
elaborate.

Michael.