[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
> 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:
> - 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 ?
> - FPropPath
> - FAncestors
I see no problem in making these available as read-only protected
> - FStream
> - FLoaded
> Used in order TParams create tmseparam items instead of TParam:
> - 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:
> - FHandle
The handle is fixed throughout the lifetime of the stream. It is set when
creating the stream, and closed when destroying the stream.
> - 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