➢The compiler creates temporary variables to hold the intermediate steps of a nested function call.
Consider the following source code which tries to decide if people having 2 different birth dates, have the same age today.
bSameAge = (Today()-nBirthdate1) div 365 == (Today()-nBirthdate2) div 365
The compiled code below corresponds to for the nested call above.
0003 CALL n003=Today()
0003 CALL n002=Difference(@n003|@nBirthdate1)
0003 CALL n001=Mod(@n002|365)
0003 CALL n006=Today()
0003 CALL n005=Difference(@n006|@nBirthdate2)
0003 CALL n004=Mod(@n005|365)
0003 CALL bSameAge=EqualN(@n001|@n004)
Some remarks about the above compiled code :
•Each temporary variable is unique and never reused. For example we could have reused n003 or n002 where we use n006 or n005, but we don't. This helps make the compiled code more legible.
Using nested function calls can be overdone. While the previous example may have been a bit extreme, surely the following is reasonable ?
nWeekday = WeekdayOf(Today())
Are there any guidelines to the use of nested function call ?
•There is no compiler limit to the depth of function call nesting you can use. You will sooner be limited by the length of the code line that forces you to scroll.
•Although you can always view the values of the temporary variables in the debugger's watch window, you will not be able to use the fly-by hints inside the source code to conveniently view the values of temporary variables.
•It will make it harder to watch the values of some intermediate step of a nested function call. Using the example above, you would have to remember that n002 is the difference in days and n001 is the age of person1. If you need to debug the value of an intermediate step, it is worthwhile writing the step yourself, with meaningful variable names.
Like everything, deciding on the subdivision of your source code is a question of common sense and, to a certain degree, personal taste.
Topic 108218, last updated on 22-Apr-2020