On 02/05/2024 10:56, Martin Frb via fpc-devel wrote:
https://github.com/llvm/llvm-project/blob/main/llvm/docs/SourceLevelDebugging.rst#debugging-information-format-1
Objective C properties exist separately from class members. A
property can be
defined only by "setter" and "getter" selectors, and be calculated
anew on each
access. Or a property can just be a direct access to some declared ivar.
I don't know if in Apple terms "ivar" has any special meaning?
ivar = instance var. Basically a regular field (as opposed to a
class/static field), i.e. the equivalent of a "property size: longint
read fsize write fsize;"
Nor if there is more to "calculated anew on each access"?
I think they mean that on each access, the getter/setter gets called again.
---------------
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.
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.
There are various optimisations to make this less costly than a naive
implementation when running on a single system. But that is the reason
why it uses a string. As Objective-C is an extension of C rather than
C++, it does not support overloading either (although due to the way its
method names are split up when calling, it can support something
syntactically similar).
Jonas
_______________________________________________
fpc-devel maillist - fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
