On 14/10/2024 20:56, Todd Allen via Dwarf-discuss wrote:
Playing devil's advocate here: Can you mix these two types of
properties? That is, something like the following (please excuse any
wrong syntax):
type
TMyRecord = record
a,b: integer;
end;
TMyClass = class
function GetProp: TMyRecord;
procedure SetProp(AVal: TMyRecord);
property MyProp: TMyRecord read GetProp write SetProp;
property MyPropA: integer read MyProp.a;
end;
That is, a read of TMyClass's MyPropA would call TMyClass.GetProp and
then return only its member a?
No, you can't. And I don't think it will be added, because then the
location of "a" is not known at compile time. (it depends on the
function result).
Currently the implementation is such that the compiler can compute the
location of the final field.
That is it must be in a "record" (inlined structure), rather than a
"class" which would have a (hidden) pointer that could be nil.
With the record, the final field is still directly known at compile
time. And it is always there (no condition such as a nil-able pointer in
the middle).
Currently it also only works for a field. Originally records did not
have functions. That has changed.
However:
I am not aware of plans to allow a getter method from a record. But it
would fulfil the condition that the compiler can resolve it at compile
time.
So currently having the location of the final field will work for all
existing cases.
Having DW_AT_Location point to the directly enclosing object will do the
same. It's my personal preference, but not a big issue.
It could even be
DW_AT_Location : location of the directly enclosing object
DW_AT_data_location : location/address of the properties data
(ignore/replace the DW_AT_data_member_location)
Both may be valuable in some future scenario.
--
Dwarf-discuss mailing list
Dwarf-discuss@lists.dwarfstd.org
https://lists.dwarfstd.org/mailman/listinfo/dwarf-discuss
