[Dwarf-discuss] Proposal: Add support for "property" with getter/setter (based on Pascal properties)

[Todd Allen]

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?

On 10/13/24 04:15, Martin via Dwarf-discuss wrote:
>
> On 13/10/2024 00:59, Adrian Prantl via Dwarf-discuss wrote:
>> On Sep 30, 2024, at 1:39 PM, Martin <lists@mfriebe.de> wrote:
>>>
>>> On 30/09/2024 19:30, Adrian Prantl wrote:
>>>> PS: One thing I left out is DW_AT_Property_Object. It wasn't clear 
>>>> to me why this wouldn't always be the address of the parent object 
>>>> of the DW_TAG_property.
>>>
>>> There is a construct where a property can point to an embedded 
>>> structure.
>>>
>>> type
>>> TMyRecord = record
>>>    a,b: integer;
>>> end;
>>>
>>> TMyClass = class
>>>    FPadding: word;
>>>    FData: TMyRecord;
>>>    FOther: TMyRecord; // Can't use the type to search for FData
>>>    property ValA: integer read FData.a;
>>> end;
>>>
>>> In that case DW_AT_Property_Forward  points to the member "a" in 
>>> "TMyRecord". This would be a DW_TAG_Member, which would have a 
>>> DW_AT_data_member_location relative to the structure FData address. 
>>> However there is no address where MyRecord is stored.
>>
>> Interesting example! In this case a DW_TAG_property_getter needs to 
>> point to the member "a" of the field FData specifically, so it can't 
>> be a reference to the DW_TAG_member "a" in TMyRecord. I can't think 
>> of a good way of preserving the access path of the field here. We 
>> could allow a DW_AT_location + DW_AT_type to allow a consumer to 
>> derive the value, but not the access path. In the general case (think 
>> something like "read FBinaryTree.left.left.right.data") we lack the 
>> expressivity to preserve which sub-field in the data structure, since 
>> DWARF does not encode expressions, only types.
>>
>> I think it would be reasonable to allow the common case of referring 
>> to a top-level field via a DW_TAG_member ref, and having an arbitrary 
>> DWARF expression in a DW_AT_location to recover the location in all 
>> other cases.
>>
> Well, I don't think we need the "access path", as in full access path.
> As you pointed out "a" could be in a nested record of TMyRecord, but I
> can't think of any case where that access path would matter.
>
> If we add DW_AT_Location:
> - keep the normal fields in the property, including the refernce to "a"
> - add DW_AT_Location to overwrite the DW_AT_data_member_location
> then, yes we have all the info we need.
>
> There is a choice to make that DW_AT_Location point directly to the data
> of the field. Or to the location of the directly enclosing object.
>
> My original idea was to describe the location of "FData" with a location
> expression, and then the debugger still adds the
> DW_AT_data_member_location to that.
>
> Currently directly specifying the location of the "pointed to field" is
> the simplest way.
>
> And currently, in Pascal, the above only works for fields in a record.
> So the address of the record containing the field should never be
> needed. But if that ever is extended (or if any other language allows)
> to use a getter method from such an object, then the object address
> would be needed for the "this" parameter.
> So maybe it is saver to use the DW_AT_Location to specify the address of
> that containing object?
>
> In either case, the nested object can be different for getter/setter. So
> that additional address must given per getter/setter.
> -- 
> Dwarf-discuss mailing list
> Dwarf-discuss@lists.dwarfstd.org