[fpc-devel] apple properties // Re: Help/Guidance please: Dwarf support for properties

[Martin Frb]

On 03/05/2024 14:17, Sven Barth via fpc-devel wrote:
> Martin Frb via fpc-devel <fpc-devel at lists.freepascal.org> schrieb am 
> Fr., 3. Mai 2024, 12:13:
>
>     In case it goes ahead, I am trying to thing of what would be
>     needed....
>     Can anyone think of any feature for Pascal properties that is not
>     covered by the below?
>
>
> A property can be marked "default". Currently only array properties, 
> but there is still the idea to implement "hoisting" of sub members 
> through single properties.
Right. I will add a "default" flag.

Out of interest (I recall having seen the discussion, but I don't recall 
the details), how would that be accessed?
a := MyObj; // will a be assigned the object or the default properties 
value?


Will that also mean multiple default properties, if the index signature 
differs?


>
> Properties of type interface or class can have an "implements" clause 
> that redirects the implementation of an interface implemented by the 
> class (note: class type properties are not yet supported by FPC, but 
> are on the ToDo list for Delphi compatibility).
>
Right. Is that relevant for the debugger though?

Or would that be the other way round? I.e. if we implemented debug info 
for interfaces, then an interface would in the debug info be a structure 
with lots of functions.
Those functions then point to the correct functions in the object.
And through the self param, would reveal the object, or in this case 
the  "implements" interface as object (allowing the debugger to forward 
resolve).

Actually, I don't think that the class debug info even includes which 
interfaces the class implements?

The Borland extension seems to have had it: 
https://github.com/llvm-mirror/llvm/blob/master/include/llvm/BinaryFormat/Dwarf.def#L390


> Oxygene introduced per setter/getter visibility and since I had need 
> of this here and then in the past I might still be inclined to 
> implement that in the future, so this might not only be for C# then.
>

Good to know, I will amend that.

-------------
I was also thinking if it might help to have a link to an inherited 
property, if only visibility is changed.
But that does not exist for functions either (though actually indirectly 
yes, through the vmt pointer).

That way the debugger could use that to avoid double listing it.

E.g. currently there is already the problem that with "strict private" 
(or private across units) an object can have several fields "MyField". 
Of the same or different type. (which I still haven't 100% dealt with in 
fpdebug).
With fields though, they are always different. With properties they may 
be a newly introduced, or a visibility change. But then the absence of 
any setter/getter would indicate that too.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freepascal.org/pipermail/fpc-devel/attachments/20240503/29078aba/attachment.htm>