What you appear to want and need is simply a string property declared on your record type that can both represent all of the member data of the record as a string, but also allow you to set it, presumably according to some formatting rules. I anticipate the following, for example:
test_var.AsString := '99'; // Sets x = 99
test_var.AsString := '99,42'; // Sets x = 99 and y = 42
test_var.AsString := '99,42,57'; // Sets x = 99, y = 42 and z = 57
One way would simply involve a property declared on your record type which performs and interprets the desired formatting when reading or writing a variable of that record type using that property, in this case, as a single string value:
type_test = record
private
function get_AsString: String;
procedure set_AsString(const aValue: String);
public
x : Integer;
y : Integer;
z : Integer;
property AsString: String read get_AsString write set_AsString;
end;
function type_test.get_AsString: String;
begin
// Return x, y and z formatted as a single string value
end;
procedure type_test.set_AsString(const aValue: String);
begin
// Unpacks values in the supplied formatted string and
// applies them to x, y, and as appropriate
end;
The implementation details of these methods is left as an exercise for you (apart from anything else the precise specification for the representation of your record type as a String
value is not provided).
The application of RTTI might allow your string format to be more generic/flexible:
test_var.AsString := 'z=99'; // Sets z = 99
You could still support this in the AsString
property-based approach as above, simply incorporating specific field naming in your read/write methods. RTTI is only necessary for complete flexibility, i.e. to allow your read/write methods to 'discover' the supported member fields rather than being coded explicitly to support specific named members.
Any methods for reading/writing values of a particular record type do not necessarily need to be part of the record type itself (although this in turn makes those methods less discoverable by consumers of the record type).
The argument for explicit AsString
support on a type is stronger than generalised methods for reading/writings record members to/from a string. Explicit support involves knowledge of implementation details, tightly coupling the AsString
methods to the type it supports. Where-as, by definition, a completely generalised method for reading/writing members of a record by name could in theory be applied to any record type, so making them part of any specific record type makes little sense.
RTTI based approaches will also be slightly less efficient due to the additional work involved in discovery using RTTI, at runtime.
In short, RTTI provides greater flexibility at the cost of complexity and some overhead.
Whether that complexity and overhead is a fair exchange for the flexibility is up to you.