[progress Communities] [progress Openedge Abl] Forum Post: Re: Is It Safe To Use Properties...

  • Thread starter Thread starter Simon L. Prinsloo
  • Start date Start date
Status
Not open for further replies.
S

Simon L. Prinsloo

Guest
Look at the call stack in the debugger (or PROGRAM-NAME(1) in a getter or setter). I came to the conclusion that there is no difference between a property without a getter/setter and a regular variable. On the other hand, if there is a getter, the compiler create a "propGet_ " method returning the same type as the property's data type and if there is a setter, the compiler creates a void "propSet_ " method, taking the input parameters that you specified in the setter. So if there is a getter, references that reads the property essentially gets replaced with a method call to the getter, unless you are already in the getter. If there is a setter, assignments are effectively converted into method calls to the setter, unless you are already in the setter. More testing, especially when we could not WAIT-FOR in functions, brought me to the conclusion that VOID METHODS seems to be compiling to constructs that are the same as, or very close to, internal procedures, while non-VOID methods compiles to construct that are the same as or similar to user defined functions. With regard to properties, setters would follow the same rules and have the same restrictions that you would experience with VOID methods and/or internal procedures, while getters would impose the same restrictions as FUNCTIONS and non-VOID methods (e.g. cannot be referenced after an indexed field in an ASSIGN statement and could not halt for user input in older versions ). In other words, in your case, properties with no getter block can be used like variables, but those with a GET(): END GET. must be treated as METHOD/FUNCTION calls. The problem is that you may not know if I have implemented a GETTER, or I may implement one later on and have an adverse effect on your code. In principle, if I suspect that these might be code, especially potentially expensive or slow code, behind a property, I will normally put it in a local variable if I am going to reference is more than once. There are cases where I intentionally write the code so that I can always reference it directly and calculate the value only once when needed, but that requires that you keep the value in a private variable and maintain a flag to indicate if you need to (re-)calculate. You also need to reset this flag for any and all of these properties whenever anything that may have an effect on them changes, which immediately opens the door for human error.

Continue reading...
 
Status
Not open for further replies.
Back
Top