I was primarily referring to what Jochen said about a mixin being a
possible solution: "could be a mixin... but if your requirement is to
avoid the creation of additional objects, then this will not work, as
the Closure will be created new every time.".
But I also looked at your code, and saw a lot of snippets that always
only saved and restored the enclosingElement field.
For that special case one could use a helper try-catch-finally wrapper
method that takes a closure that executes the actual setting of relevant
references and the visit.
And if one could live with the overhead of references being saved &
restored which will not be changed, one could use the same method for
(maybe) all of the cases you have.
Now imagine that try-catch-finally wrapper method was an inlined
closure, and it inlines the closure it receives, then you get a solution
to your problem with very little overhead.
On 22/11/2020 21:28, Milles, Eric (TR Technology) wrote:
I'm not understanding how inlining a closure expression could help reduce the
burden of saving state to a temporary variable and then restoring it after
execution, unless there was some additional AST processing.
<zip>
