I've been extending a system that is mainly in Groovy. It has a database that includes thousands of scripts, each of which gets turned into a Script object. Most are very small, but a few are large. Often one script calls another. In fact, the call hierarchy of scripts can get pretty deep. There is nothing to prevent these scripts from being recursive, though I don't think any are.
I ran into a problem where bindings were being reused inappropriately, and it made me study Scripts in more detail. It looks to me like a script that calls itself recursively will reuse the original binding. That is because you set the binding with setBinding and then just use the existing binding when you call evaluate(). I would prefer a design in which you would pass in the binding to evaluate() so that a script could call itself recursively or you could have two concurrent evaluations of a script in different threads. Now, it is possible that recursion works fine on Scripts. I haven't tested it. Perhaps the execution of a Script clones the relevant info including the binding and changing the binding during the execution of a Script will have no effect on the Script. I couldn't find any documentation that said anything about this. I will do some experiments, but it will be a lot of work because I have to change some things in our system before I can use it for the experiments. So, I thought I would ask here first. I tried cloning a Script. I know that compiling a Script creates a subclass of Script and the result is a unique instance of that class. I imagined that the instance held the binding and used it as a delegate. I figured we could clone the Script instance, set a new binding, and all would be well. However, Scripts don't seem to like to be cloned. If Scripts don't like to call themselves recursively, is there any way to make a copy so each call can be to a unique instance? -Ralph Johnson
