[fpc-devel] Class field reordering

michael.vancanneyt at wisa.be michael.vancanneyt at wisa.be
Wed Jul 18 09:33:09 CEST 2012

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

> 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 

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:


More information about the fpc-devel mailing list