Re: Dynamic arrays of record/object

"Rob Kennedy" <me3@xxxxxxxxxxx> wrote in message
news:63r7e6F2937anU1@xxxxxxxxxxxxxxxxxxxxx
[...]
Don't have a property that directly writes the value of that field.
If you assign a new value of the property, then FCount is no longer
an accurate representation of the length of the array.

You don't really even need FCount. The array already knows its own
length, and it's easy to detect with the Length function.

If I may *** in with some code that won't really contribute to the
problem, I'd like to observe that 'Count' is a fine example of a
useful concept, a 'computed' or 'derived' property.

If you have a property Data (SectionData in the OP's case), backed by
an FData dynamic array, you can at any point (a) determine the value
of the length of the array, and (b) change the length of the array.
If that is a useful way of interacting with the data, it is useful to
introduce a property for it.

type
TSomething = class(TObject)
private
FData: array of TItem; { TItem to be declared elsewhere }

function GetCount: Integer;
procedure SetCount(const Value: Integer);
protected
property Count: Integer read GetCount write SetCount;
end;

function TSomething.GetCount: Integer;
begin
Result:=Length(FData);
end;

procedure TSomething.SetCount(const Value: Integer);
begin
SetLength(FData, Value);
end;

Note how the Count property is completely dynamic. You can read its
value, set it to a different (or the same) value, and it will work,
but its value is not stored explicitly anywhere in your code.

Did I mention that I like properties?

Groetjes,
Maarten Wiltink


.

Quantcast