Alternatives to try/finally code structure

Next Topic
 
classic Classic list List threaded Threaded
13 messages Options
12
MG
Reply | Threaded
Open this post in threaded view
|

Re: Alternatives to try/finally code structure

MG
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>
Reply | Threaded
Open this post in threaded view
|

RE: Alternatives to try/finally code structure

Milles, Eric (TR Technology)
> 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.

This may be in alignment with what you are saying.  If I had a method "auto(oldValue, newValue)" that creats an inline AutoCloseable AIC instance, I could package up capture, mutate and restore within the enclosing scope.  
try (auto(field, value)) {
   ...
}

would translate to this:

try (new AutoCloseable() {
  def tmp = field;
  {
    field = value
  }
  @Override
  void close() {
    field = tmp
  }
}) {
   ...
}

"field" could be any VariableExpression, PropertyExpression, AttributeExpression or FieldExpression -- anything that is read/write.  "value" could be just about any Expression.

This way, the try statement could be its normal self.  There could be anything in the try block, there could be catch blocks and there could be a finally block as well.  And you could reuse this anywhere an AutoCloseable is accepted, so withCloseable is an option in place of try.
Reply | Threaded
Open this post in threaded view
|

RE: Alternatives to try/finally code structure

Milles, Eric (TR Technology)
Or I could still call it "push" and it could look like this:

try (field.push(value)) {
   ...
}

------

> 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.

This may be in alignment with what you are saying.  If I had a method "auto(oldValue, newValue)" that creats an inline AutoCloseable AIC instance, I could package up capture, mutate and restore within the enclosing scope.  
try (auto(field, value)) {
   ...
}

12