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
_______________________________________________
fpc-devel maillist - fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
