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

[Jonas Maebe]

On 02/05/2024 22:01, Martin Frb via fpc-devel wrote:
> On 02/05/2024 20:59, Jonas Maebe via fpc-devel wrote:
>>
>>
>>> ---------------
>>>
>>> I don't have background on the Apple properties.
>>
>> It's not Apple, but Objective-C.
>>
>>> property goes from the member to the property strikes me as odd. 
>>> (first example of dwarf)
>>> It indicates, that the property is only meant to be found when 
>>> starting at the member?
>>
>> Objective-C also knows the concept of "computed properties", which are 
>> not tied to a particular field. I don't immediately see how the 
>> proposal deals/would deal with that.
> Ok, I don't know how to read that, but potentially many fields could 
> link to the same property.
> 
> Do those properties need a field at all?

No, as far as I can tell they're more or less equivalent to Pascal 
properties.

>>> Also the Apple spec uses strings (names) to refer to the getter/setter.
>>> I don't know if there is a particular underlying need. It's more 
>>> costly than a reference. Also It gets problematic if the getter is in 
>>> an embedded record, or if there are overloaded functions, ....
>>
>> It doesn't use a symbol name, but a selector name. Objective-C method 
>> dispatching mostly does not happen using a VMT, but by looking up a 
>> (hash of a) selector in a table. "Calling a method" is called "sending 
>> a message to" in Objective-C lingo; it's also how it can fairly 
>> transparently support working with remote objects.
> 
> ok. Explains maybe half...
> 
> I am not immediately sure if dwarf has anything to describe dispatching. 
> Or if this is just left for the debugger to know. Which is ok, with 
> custom tags that are for Objective-C only.

Yes, Objective-C's runtime has a publicly documented API. It has C 
functions that you can use to call mathods with a particular name on a 
particular object (or, in Objective-C terminology, send a message by 
name to an instance).

> The other part that I really don't understand is, why you find the 
> property from the field, and not the other way round (above)?
> Does that mean the code/user would not start with "object.my_property" 
> but rather do "object.field as property"?

It's because except for computed properties, properties are explicitly 
tied to a particular field. They provide getters and/or setters for a 
particular field.



Jonas