I know that I'm beating a dead horse here, but "absolute" is terible and should be always avoided. The reason for this is that absolute circumvents any typechecking
E.g.
type
TTest = record
A: Integer;
B: Double
end;
var
t: TTest;
a: Integer absolute t.A;
B: Double absolute t.B;
begin
t.A := 42;
t.B := 3.14;
WriteLn(a, ' ', b);
ReadLn;
end.
Works really nice, but what if I now decide to change the type of TTest (which btw could be in a completely different unit, by a person who does not know that this code using absolute exists):
type
TTest = record
A: Double;
B: Double
end;
var
t: TTest;
a: Integer absolute t.A;
B: Double absolute t.B;
begin
t.A := 42;
t.B := 3.14;
WriteLn(a, ' ', b);
ReadLn;
end.
Now the program compiles fine, not a single hint or warning. But when running the result is now "0 3.14" rather than "42 3.14", which is wrong. This is the worst kind of error, one where it silently produces a wrong result without any crash, warning or even a compiler hint.
This is just an error waiting to happen. You should always write your code in a way that errors are cought as early as possible, best is if the compiler itself finds your error and does not compile. This is the complete opposite of this. In a perfect world we would have compilers that exactly know what you want to do and if you do something wrong, like the thing above, tell you "Sorry Dave, I can't let you do that". But sadly this is impossible so we as programmers need to restrict ourselves to tools that help the compiler to help us. But absolute is like telling the compiler "I don't need any help, I will never do mistakes"
For an example, if I do the same in C++, using references, which basically is the same as absolute but as active part of the typesystem it fully incorporates typechecking:
struct {
int A;
double B;
} t;
int &a = t.A;
double &b = t.B;
t = { .A = 42, .B = 3.14 };
std::cout << a << " " << b << std::endl;
}
Changing the A field to double will cause a compiler error, which is good, because accessing an double as an integer is most probably going to be an error.