Jump to content

The Merits of Helper/Loop Functions in Recursive CFs


This topic is 4237 days old. Please don't post here. Open a new topic instead.

Recommended Posts

I'm trying to figure out the pros/cons of using a Loop/Helper function to handle the recursion in a CF

Specifically, are there

  1. speed or

  2. upper limit

benefits to using a "helper" or "looper" function instead of combining all the steps into a single or is that simply for readability?

What about using the CustomList function to handle the recursion?

Link to comment
Share on other sites

I would have thought that using a helper function for any looping calculation would make the overall calculation non-tail recursive, and therefore limit the function to the smaller ~10,000 recursion limit. A test I tried just now proved me wrong. I consider the benefit of not exposing "dummy" parameters a big deal, but I prefer to use variables to pass data up and down the function call stack rather than parameters for a helper function. See one of my UUID functions for an example. This can make the calculation more complicated, but it also means the function I write has no dependencies, which is helpful when copying useful functions a la carte between files.

Link to comment
Share on other sites

Well, the thing about $variables is that their scope is much larger than the custom function itself - so one has to be absolutely sure a similarly named variable is not declared elsewhere. That's not so easy to achieve, esp. when one is copying functions across files.

Link to comment
Share on other sites

Variable management for custom function is indeed important to be very careful about. I accomplish it with a combination of a naming convention and hygienic code. When I use variables for passing data between iterations of a function, I always name the variable something like "$~ABC.variable", where "ABC" is a mini-namespace for the function or a collection of functions, and the tilde "~" is a convention for marking the variable as "private" even though FileMaker doesn't enforce such security. To be extra rigorous (and verbose), you could just use the full name of the function. I also make sure to null-out any such variables in a garbage collection step at the end of a function to avoid unintended side effects (unless those variables are used to share information between different functions). I stick to local $variables rather than global $$variables when possible to minimize the scope of any variable I neglect to purge.

It can seem like a lot to keep track of, but I think it's worth it — obviously, since I do it. It's easier to keep track of when you're used to it. I wont always do this sort of thing for simpler functions due to the performance overhead of the structure you see in that UUID function; but I like having it in my toolbox.

Link to comment
Share on other sites

This topic is 4237 days old. Please don't post here. Open a new topic instead.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.