Re: [fpc-devel] apple properties // Re: Help/Guidance please: Dwarf support for properties
On 03/05/2024 12:56, 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. Does FPC create such Objective-C code / properties? If yes, how does it decide on how to translate "property Foo..."? FPC does not currently support properties in Objective-C classes. Jonas ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] apple properties // Re: Help/Guidance please: Dwarf support for properties
On 03/05/2024 14:17, Sven Barth via fpc-devel wrote: Martin Frb via fpc-devel 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.___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] apple properties // Re: Help/Guidance please: Dwarf support for properties
Martin Frb via fpc-devel 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. 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). 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. Regards, Sven ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] apple properties // Re: Help/Guidance please: Dwarf support for properties
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. Does FPC create such Objective-C code / properties? If yes, how does it decide on how to translate "property Foo..."? ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] apple properties // Re: Help/Guidance please: Dwarf support for properties
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? # Proposal to implement "properties" for Pascal ## Background Pascal has a property construct, that allows a "variable like" identifier, which can either point to a field (member variable) or a getter/setter function. They can be read/write, read only, write only. TFoo = class FField: integer; function GetProp: integer; procedure SetProp(AVal: Integer); property MyProp: integer read GetProp write SetProp; property MyOtherProp: integer read FField; end; Properties can exist in a structure, interface, or on a global level. Properties can have one or more array like indexes. TFoo = class function GetProp(AIdx:word; AIdx2: boolean): integer; procedure SetProp(AIdx:word; AIdx2: boolean; AVal: Integer); property MyProp[AIdx:word; AIdx2: boolean]: integer read GetProp write SetProp; end; Properties can share a method, and provide an index (constant) to identify which property called the method. TFoo = class function GetProp(AIndex: Integer): integer; procedure SetProp(AIndex: Integer; AValue: integer); property MyProp1: integer index 1 read GetProp write SetProp; property MyProp2: integer index 2 read GetProp write SetProp; end; Properties can be streamed and therefore can have a default value (constant or via function). They can also have a "stored" value (function) indicating if they need to be stored in the stream. Properties can be elevated to a higher visibility (private/public) in inherited classes. There may be partial overlaps with properties in Objective-C and C# ## Proposed Changes Introducing a new tag DW_TAG_PROPERTY or DW_TAG_PROPERTY_PASCAL This tag can occur anywhere where DW_TAG_MEMBER can occur. It can also occur on a global scope. It can have DW_AT_NAME DW_AT_TYPE DW_AT_ACCESSIBILITY DW_AT_decl_column, DW_AT_decl_file and DW_AT_decl_line. It can then contain any of DW_TAG_PROPERTY_SETTER DW_TAG_PROPERTY_READER DW_TAG_PROPERTY_DEFAULT DW_TAG_PROPERTY_STORED Each of them can have DW_AT_PROPERTY_FORWARD reference/constant refernce to the field or function DW_AT_PROPERTY_OBJECT reference/expression/constant the object on which the value is stored (value for DW_OP_push_object_address) can be omitted for inherited classes, if it computes to the same as the current class A getter (also "default" and "stored" should be a function returning the same type as the property. It should either take no arguments or only DW_AT_object_pointer A setter should be a procedure, it should take optional DW_AT_object_pointer and one argument of the same type as the property. Instead of having attributes grouped in DW_TAG_PROPERTY_SETTER/... all attribute could exist top level, in 4 versions. That would be shorter if no object needs to be specified. But it is less flexible for later additions. For indexed properties the DW_TAG_PROPERTY also has DW_TAG_PROPERTY_INDEX_LIST containing one or more DW_TAG_PROPERTY_INDEX DW_AT_NAME DW_AT_TYPE DW_AT_VALUE reference or constant or expression (returning value) DW_AT_IS_PROPERTY_VALUE flag DW_AT_NAME and DW_AT_TYPE can be optional. They can be gotten from the linked procedure DW_AT_VALUE is optional. It is used when properties share a getter. DW_AT_IS_PROPERTY_VALUE is optional. It can be used to specify the position of the "assigned value" in a setter. If not specified the assigned value will be passed as the last parametr. To change visibility of an inherited property, DW_TAG_PROPERTY DW_AT_NAME DW_AT_ACCESSIBILITY OFF TOPIC: For C# it may be of interest to allow DW_TAG_PROPERTY_SETTER/... to have their own DW_AT_ACCESSIBILITY For C# it may be of interest to allow an inlined function declaration instead of DW_AT_PROPERTY_VALUE ## References FreePascal property doc https://www.freepascal.org/docs-html/ref/refse27.html APPLE extension for Objective-C https://github.com/llvm/llvm-project/blob/main/llvm/docs/SourceLevelDebugging.rst#debugging-information-format-1 ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] apple properties // Re: Help/Guidance please: Dwarf support for properties
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
Re: [fpc-devel] apple properties // Re: Help/Guidance please: Dwarf support for properties
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? 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. I don't know if that table is precomputed / I.e. get completely created at compile time => in which case the location of the looked up hash would be known in the table, and the address of the method could be gotten via a dwarf expression? 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"? I am trying to understand if there is any common ground with properties in Pascal. I've ask if they (dwarf makers) see potential for our properties https://lists.dwarfstd.org/pipermail/dwarf-discuss/2024-May/thread.html So, I am trying to figure out were those Apple tags fit into it, and how/if I treat them in that discussion. (the Borland ones, have no docs to be found) However from what I have seen so far, I do think there are fundamental differences. Pascal properties should have - the property as a declaration that is a start point (except for being owned by a class / but also exists without) - links to other entities starting at the property (or no links, and duplication of accessor declarations) Maybe there is still stuff that could be proposed as share-able? ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] apple properties // Re: Help/Guidance please: Dwarf support for properties
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
