[fpc-devel] Class field reordering

[Martin Schreiber]

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

TWriter:
- FPropPath
- FAncestors

TReader:
- FStream
- FLoaded

Used in order TParams create tmseparam items instead of TParam:

TCollection:
- FItemClass

Used to unify memorystreams/files/pipes/sockets/stringstreams:

THandlestream:
- FHandle

TMemoryStream:
- FCapacity

Why must these fields be private?

Thanks, Martin