This is substantially lower-level than is probably warranted, but what
you're looking for could be implemented by pushing the values onto the
stack immediately at the entry point.
On Tue, Nov 24, 2020, 15:36 Milles, Eric (TR Technology) <
eric.mil...@thomsonreuters.com> wrote:
> > since you seeme
> since you seemed to say in the beginning that you did not want to create
> objects (if I read this correctly), why creating AutoCloseable instances here
> would not pose a problem ?)
Best case scenario is that I get the same performance and memory footprint of
the original code (included belo
Something along that line, yes :-)
(Just wondering, since you seemed to say in the beginning that you did
not want to create objects (if I read this correctly), why creating
AutoCloseable instances here would not pose a problem ?)
Cheers,
mg
On 23/11/2020 00:45, Milles, Eric (TR Technology) w
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()
}
}
ide the bar method's scope.
>
>
>
> My goal is to eliminate repetitious typing of assigning the current value to
> a temporary variable, assigning the next value to the field and at the end
> restoring the previous value.
>
>
>
>
>
> From: Leo Gertsenshtey
ary variable, assigning the next value to the field
and at the end restoring the previous value.
*From:* Leo Gertsenshteyn
*Sent:* Saturday, November 21, 2020 5:34 PM
*To:* dev@groovy.apache.org
*Subject:* Re: Alternatives to try/finally code structure
Hi Eric,
Am I correctly interpreting
nshteyn
Sent: Saturday, November 21, 2020 5:34 PM
To: dev@groovy.apache.org
Subject: Re: Alternatives to try/finally code structure
Hi Eric,
Am I correctly interpreting that baz() in the above examples calls into 3rd
party code and that code has direct reference to the state and controls the
state v
Hi Eric,
Am I correctly interpreting that baz() in the above examples calls into 3rd
party code and that code has direct reference to the state and controls the
state variables' lifecycle? If that's not the case, there may much much
simpler solutions involving intermediate objects, recursion, etc.
Groovy Devs,
I have been pondering how to automate the writing of try/finally blocks used to
unconditionally restore object state. Does anyone know of a Groovier way to do
something like this before I pursue a macro method, an AST transformation, or
something more involved? It currently requi
16 matches
Mail list logo
