Is it accurate to rephrase your goal as snapshotting some
variable-per-scenario current state, running code, and then rolling
back any changes to the snapshot?
On Sat, Nov 21, 2020 at 8:02 PM MG wrote:
>
> Hi Eric,
>
> do these references (it seems you do not need to open the can of worms that
Hi Eric,
do these references (it seems you do not need to open the can of worms
that is deep copying in your problem) you need to save/restore reside in
a single class, or could such a class be introduced (maybe in a generic
manner) ? I am unclear how wide the different scenarios are here you
I have been thinking about this, and I think I might need to go back on
my comment on "Code of Conduct" as a name - maybe Groovy needs
something, that better expresses how non-toxic and constructive the
environment here is, especially when compared to some of the worse
examples out there, so I
Thanks for the reply. So if I use an AutoCloseable, I would have something
like:
class Foo {
private state
def bar() {
def temp = state
state = newState
try ({ -> state = temp } as AutoCloseable) { // or rewrite this line using
withCloseable
baz()
}
}
}
In my case,
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,
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
