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
[fpc-devel] apple properties // Re: Help/Guidance please: Dwarf support for properties
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? Nor if there is more to "calculated anew on each access"? --- I don't have background on the Apple properties. But the fact that the link between a "field" (tag_member) and the 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? For FPC properties that is the other way round. The property would have to point to the field. (or function) 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, - There do exist Borland properties https://android.googlesource.com/platform//prebuilts/clang/host/linux-x86/+/b669748458572622ed716407611633c5415da25c/clang-r416183d/include/llvm/BinaryFormat/Dwarf.def But I could not find any details at all ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Default properties
> On Sep 10, 2018, at 4:23 PM, Ryan Joseph wrote: > > I think I can use tcallcandidates.create_operator to test this but what do I > pass for the call param node? I didn’t get an answer on this but I was able to figure it out for myself, albeit only for arithmetic operators, i.e. class operator + (left: TWrapper; right: integer): TWrapper; ppn:=ccallparanode.create(right.getcopy,ccallparanode.create(left.getcopy,nil)); ppn.get_paratype; candidates:=tcallcandidates.create_operator(optoken,ppn); if candidates.count > 0 then begin candidates.get_information; result := candidates.choose_best(tabstractprocdef(operpd),false) > 0; end; For assignment operators like: class operator := (right: integer): TWrapper; the code doesn’t return any candidates. I think this is because the tcallparanode is wrong but I don’t know what to provide. Any ideas? Regards, Ryan Joseph ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Default properties
One more question. With the syntax: wrapper + 1 I get to the point where I have 2 nodes parsed. p2 is an ordconst node (the value “1") and p1 is a load node (wrapper, which is a record). I need to check the resultdef for p1 to see if the + operator is overloaded so I can determine if the base record or the default property takes precedence. I think I can use tcallcandidates.create_operator to test this but what do I pass for the call param node? from pexpr.pas: p2:=sub_expr(succ(pred_level),flags+[ef_accept_equal],nil); case oldt of _PLUS : p1:=caddnode.create(addn,p1,p2); _MINUS : p1:=caddnode.create(subn,p1,p2); _STAR : p1:=caddnode.create(muln,p1,p2); _SLASH : p1:=caddnode.create(slashn,p1,p2); _EQ: p1:=caddnode.create(equaln,p1,p2); _GT : p1:=caddnode.create(gtn,p1,p2); Regards, Ryan Joseph ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Default properties
> On Sep 7, 2018, at 6:27 PM, Sven Barth via fpc-devel
> wrote:
>
> tcallcandidates in htypechk.pas is your friend. That is the *only* class that
> deals with overload resolution and collects the eligible overloads from
> various sources (e.g. loaded units, current type, helper types). Essentially
> you only need to search for a procsym with the name of method inside the
> default field (all proceeds with the same name share the same procsym) and
> pass that on, the remainder of tcallcandidates will deal with overload
> resolution (you only need to make sure that the correct "Self", namely the
> default field is picked for that).
>
Thanks, I got this working.
Just a general question. Can you clarify the difference between “tloadnode”,
“tsubscriptnode” and “tcallnode”? I want to make sure I’m using them correctly.
I ask because I’m trying to parse:
wrapper + 1 { wrapper being a record with a default property }
“wrapper” is being parsed as a load node but I want to convert it to
“wrapper.helper” by appending the default property. I found I can make a new
subscript node using the existing load node but is that the preferred method?
p1:=csubscriptnode.create(default_property,p1); { p1 being the load node for
“wrapper” }
Regards,
Ryan Joseph
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Default properties
Ryan Joseph schrieb am Fr., 7. Sep. 2018, 11:59: > I’m moving my technical questions about default properties here so I don’t > clutter up the other list. I’m still new to the compiler please bear with > me. > > The first problem I’m having is how to resolve duplicate functions with > overloads. For example in TWrapper there’s multiple overloads for DoThis > and we need to determine if TWrapper.DoThis should use TWrapper or the > THelperA from the default property. > > type > THelperA = record > procedure DoThis; > end; > > type > TWrapper = record > objA: THelperA; > property helperA: THelperA read objA write objA; default; > procedure DoThis(param: integer); overload; > procedure DoThis(param: string); overload; > end; > > > var > wrapper: TWrapper; > begin > wrapper.DoThis(1); // DoThis is from TWrapper but how can we > determine this? > > > > What I’m narrowing in on is: > > in pexpr.pas do_member_read() takes the load node and converts it to a > call node and this is where I need to determine what definition the > function belongs to. So in the example above we get “DoThis” how can we > determine if TWrapper or THelperA has a matching function with matching > parameters? searchsym_in_record usually returns the correct definition but > I need to scan 2 possible definitions instead of just the first one > specified in the load node. > > do_proc_call() parses parameters into a tcallparanode which is good. > > do_typecheckpass on the tcallnode from do_proc_call() will find procsym > candidates in the record def which the node was created with. I would use > this to query but it forces a syntax error which isn’t what I want. > > Hopefully that makes sense. So my question is, is there an existing way to > search a tabstractrecorddef given a name and parameter list and return a > found or not found answer? I could start pulling stuff out of > do_typecheckpass() but I suspect there’s already a way to do this. > tcallcandidates in htypechk.pas is your friend. That is the *only* class that deals with overload resolution and collects the eligible overloads from various sources (e.g. loaded units, current type, helper types). Essentially you only need to search for a procsym with the name of method inside the default field (all proceeds with the same name share the same procsym) and pass that on, the remainder of tcallcandidates will deal with overload resolution (you only need to make sure that the correct "Self", namely the default field is picked for that). Regards, Sven > ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
[fpc-devel] Default properties
I’m moving my technical questions about default properties here so I don’t clutter up the other list. I’m still new to the compiler please bear with me. The first problem I’m having is how to resolve duplicate functions with overloads. For example in TWrapper there’s multiple overloads for DoThis and we need to determine if TWrapper.DoThis should use TWrapper or the THelperA from the default property. type THelperA = record procedure DoThis; end; type TWrapper = record objA: THelperA; property helperA: THelperA read objA write objA; default; procedure DoThis(param: integer); overload; procedure DoThis(param: string); overload; end; var wrapper: TWrapper; begin wrapper.DoThis(1); // DoThis is from TWrapper but how can we determine this? What I’m narrowing in on is: in pexpr.pas do_member_read() takes the load node and converts it to a call node and this is where I need to determine what definition the function belongs to. So in the example above we get “DoThis” how can we determine if TWrapper or THelperA has a matching function with matching parameters? searchsym_in_record usually returns the correct definition but I need to scan 2 possible definitions instead of just the first one specified in the load node. do_proc_call() parses parameters into a tcallparanode which is good. do_typecheckpass on the tcallnode from do_proc_call() will find procsym candidates in the record def which the node was created with. I would use this to query but it forces a syntax error which isn’t what I want. Hopefully that makes sense. So my question is, is there an existing way to search a tabstractrecorddef given a name and parameter list and return a found or not found answer? I could start pulling stuff out of do_typecheckpass() but I suspect there’s already a way to do this. Regards, Ryan Joseph ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
[fpc-devel] referenced properties vs value properties
I think the Delphi language has a little problem when it comes to properties. I consider C/C++ to be a value language or maybe even a const language where addresses of classes and fields are constant or hard coded into instructions. While Delphi is more of a reference language or pointer language where addresses of classes are stored in data pointers which are used via instructions. The closest thing to a c++ class is a record in Delphi. Delphi classes are different from a c++ class, in Delphi a class when instantiated returns a pointer to a class in memory. This referenced design of Delphi is pretty handy, it allows code to refer to the same memory via different pointers which all point to the same memory. However I do consider properties in it's current design to somewhat break with this referenced design. Properties in Delphi are more like a value type, they/the properties also works on values, the read/write values or records or even entire arrays. This more or less seems like a design mistake. Perhaps properties should have been always referenced as well just like Delphi classes. (Think of a referenced property as a var parameter versus a copy parameter The var parameter would allow changes, while the copy parameter does useless changes.) The problem with properties currently is that it does not allow partial modification of records or arrays, when a property is of type record or array it's a everything or nothing situation, either the entire record/array is overwritten/returned or nothing at all, this is very inconvenient and also bad for performance. Delphi programmers have to fall back on pointer types for value types to be used with properties. So Delphi programmers would need to create pointer types again and turn properties into pointer types. One example of somewhat bad programming is record operator overloading which also requires two values apperently, this means the properties will have to be dereference for example: C = A^ * B^ The operators themselfes do not seem to work with pointer types, so pointers will have to be deferenced, quite a mess. The solution could be to introduce referenced properties. These properties under-water always work with pointers to fields, records, arrays and so forth. This frees the programmer from having to deal with pointers and pointer types and pointer dereferencing and reduces coding mistakes and also makes coding more efficient/faster/less code needed. A possible syntax could be as follows: type TSomeClass = class private protected mMyArray : TSomeBigArrayType; public referenced property SomeBigArray : TSomeBigArrayType read mMyArray; end; (a write mMyArray would be superflous but could also be allowed for easy changing between referenced and non-referenced/value properties, but simply ignored by compiler). The above syntax would treat access to SomeBigArray via a pointer under water. So writing: SomeClass.SomeBigArray[100] := 500; would automatically retrieve a pointer to the array and apply the index operator on the dereferenced pointer, instead of reading the entire array onto a stack copy and then overwrriten entire 100 and then dumping the entire array into obvlious with the code having no effect as it would in Delphi, where this to be a static array ;) The code might happen to work for dynamic arrays, since those are too pointers underneath, however for static arrays or for example records, the useless behaviour would be there. Other problems with properties as already indicated: property MyRecord : TRecord read mMyRecord MyRecord.SomeField := 100 - currently leads to useless code, the record would be copied onto stack, modified and dumped. Again the programmer has to write: property MyRecord : PRecord read GetMyRecordPointer; MyRecord.SomeField := 100; // now it would work via a pointer, because the programmer programmed it like that. Delphi's referenced properties would do away with this extra code and do it automatically as follows: referenced property MyRecord : TRecord read mMyRecord; MyRecord.SomeField := 100; An alternative syntax could also be: property MyRecord : TRecord access mMyRecord; or as I already wrote a long time ago: property MyRecord : TRecord address mMyRecord; or perhaps: property MyRecord : TRecord reference mMyRecord; Anything to solve the current situation would be nice, how would you solve the problem and automate it ? For now it seems best to avoid records as the plague and always use classes. There is one catch22/drawback, classes don't have operator overloading. However somebody wrote record operators are slow so perhaps it's for the better. Bye, Skybuck. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] referenced properties vs value properties
Skybuck Flying schrieb: I think the Delphi language has a little problem when it comes to properties. I consider C/C++ to be a value language or maybe even a const language where addresses of classes and fields are constant or hard coded into instructions. While Delphi is more of a reference language or pointer language where addresses of classes are stored in data pointers which are used via instructions. A closer look will reveal that references had to be introduced into the C++ language, in order to make operators work with certain data types (arrays...). The closest thing to a c++ class is a record in Delphi. Closest comes the Object type, but Borland/CodeGear decided to drop that useful type, and moved part of its features into records (methods...). FPC still supports Object very well. The problem with properties currently is that it does not allow partial modification of records or arrays That's due to the (possibly) virtual getters/setters, which make properties a really useful language feature. If you want references, then use data fields (var) instead of properties. The operators themselfes do not seem to work with pointer types, so pointers will have to be deferenced, quite a mess. See C++. DoDi ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] referenced properties vs value properties
On 20/09/2011 13:21, Skybuck Flying wrote: The problem with properties currently is that it does not allow partial modification of records or arrays, when a property is of type record or array it's a everything or nothing situation, either the entire record/array is overwritten/returned or nothing at all, this is very inconvenient and also bad for performance. This is not the prolem with properties. This is what property means in pascal. This is the reason why there is a property at all. If you don't want that, do not use a property, just use a field (member/variable) instead. you can always do TFoo =Class public Bar: TSomeRecord; // field/variable end; And all will work. The main reason to use a property property Bar: TSomeRecord read Fbar write FBar is to declare that the implementer reserves the right, to later put getter/setter function/procedures in place It tells the compiler, that while the developer did not yet write any such code, the compiler should/must protect Bar in a way that any code referring to it, will work, if getter/setters are written. But with a getter, Bar is a function result = so you can not do GetBar().xyz := 1 At least not meaningful: because you do not have the original FBar, you only have a temporary copy returned by GetBar. Even if pascal would have functions that return lvalues, GetBar could have created a result on the fly. There may not be a FBar variable at all. function GetBar: TSomeRecord; begin Result.xyz := random(5); end; With this function, what you suppose that Bar.xyz := 1; should do? Since Bar is GetBar, which retturns a record created on the fly, that will be dropped straight away The only way ossible would be for the compiler to translate it into tmp := Bar; tmp.xyz := 1; Bar:=tmp; which would be the same as tmp := GetBar(); tmp.xyz := 1; SetBar(tmp); And SetBar could have plenty of side effects, that do far more than just updating xyz.The original code never said to update the entire Bar = so it must not be translated to do so. So again: using the keyword property means =assume there is no variable at all; assume it may be a function, getter/setter If you do not want that, do not use it. There is no rule, that you must use properties. Making a field public accessible is absolutely ok. Most peopl edo not do it = because, if uou do not have a specific reason to do it, then using property means that at absolutely no cost, you can reserve the possibility of future extension should you need to. Hence, unless you have a good reason not to use property, you should use it. But if your design does not allow for it, do not use it. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] += with properties
On 01/13/2011 02:25 AM, Hans-Peter Diettrich wrote: This would result in the same error, because x.a is not an lval. The example that make me ask here was Form1.Caption := Form1.Caption + '.'; -Michael ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] += with properties
+= does work for variables, even Strings. AFAIR, there already has been a discussion about += and friends for properties. In fact I don't see why the compiler not just generates x.a := x.a + y from x.a += y before doing any code generating, disregarding what x.a is. Of course an error message will occur if x.a is not writable for any reason. Thanks, -Michael ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] += with properties
On Wed, Jan 12, 2011 at 21:24, Michael Schnell mschn...@lumino.de wrote: += does work for variables, even Strings. AFAIR, there already has been a discussion about += and friends for properties. In fact I don't see why the compiler not just generates x.a := x.a + y from x.a += y before doing any code generating, disregarding what x.a is. Of course an error message will occur if x.a is not writable for any reason. Blindly replacing a += b with a := a + b may lead to a semantic change if a is an expression with side-effects. Nevertheless, I do think that implementing += for properties is a good idea, but unfortunately FPC developers disagree. -- Alexander S. Klenin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] += with properties
On 01/12/2011 04:48 PM, Alexander Klenin wrote: Blindly replacing a += b with a := a + b may lead to a semantic change if a is an expression with side-effects. Nevertheless, I do think that implementing += for properties is a good idea, but unfortunately FPC developers disagree. I do see that also properties could show site effects when used in a += expression, as they are accessed twice. But is this (in nearly all cases) not exactly what the user would expect ? -Michael ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] += with properties
On Wed, 12 Jan 2011, Michael Schnell wrote: On 01/12/2011 04:48 PM, Alexander Klenin wrote: Blindly replacing a += b with a := a + b may lead to a semantic change if a is an expression with side-effects. Nevertheless, I do think that implementing += for properties is a good idea, but unfortunately FPC developers disagree. I do see that also properties could show site effects when used in a += expression, as they are accessed twice. But is this (in nearly all cases) not exactly what the user would expect ? Most of the time, yes. But there are some subtleties with interfaces and reference counting, which could bite you in the leg. (as they already have for some people). Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] += with properties
On 01/12/2011 05:01 PM, michael.vancann...@wisa.be wrote: reference counting, which could bite you in the leg. (as they already have for some people). I see. _Hidden_ side effects :) -Michael ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] += with properties
In our previous episode, michael.vancann...@wisa.be said: exactly what the user would expect ? Most of the time, yes. But there are some subtleties with interfaces and reference counting, which could bite you in the leg. (as they already have for some people). Moreover, that IMHO the c operators are mostly meant for porting of existing C code. And I never saw C code with properties :-) ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] += with properties
Michael Schnell schrieb: += does work for variables, even Strings. AFAIR, there already has been a discussion about += and friends for properties. In fact I don't see why the compiler not just generates x.a := x.a + y from x.a += y before doing any code generating, This would result in the same error, because x.a is not an lval. DoDi ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
