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.
Thi
> 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
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
Or an alternative where the method creates an AutoCloseable instance that fits
into a try-with-resources:
class Foo {
def bar() {
try (push(field1 = value); push(field2)) {
baz()
}
}
}
"push" would create something that has read/write access to "field1".
Assignment "field1 =
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.
macro method take 2:
class Foo {
def bar() {
push { field1 = value, field2 -
If Groovy would support closure-block constructs ("inlining closures"),
this could be overcome without having to resort to writing one's own
macro (which is more effort, especially if you do not already have a
seperate macro module set up in your project). I still think inlining
closures in cas
Yes, snapshot and rollback.
Here is a concrete example of the pattern:
https://github.com/groovy/groovy-eclipse/blob/master/base/org.eclipse.jdt.groovy.core/src/org/eclipse/jdt/groovy/search/TypeInferencingVisitorWithRequestor.java#L430
On 21.11.20 20:29, Milles, Eric (TR Technology) wrote:
[...]
I was thinking of something like this so as not to overload the try keyword:
class Foo {
def bar() {
push (field1 = value, field2) { // AST would be re-written to
try/finally like Scenario 1/2
baz()
}
}
