The problem is most, but not all, cases = fit that pattern.  Some times I have a button to click, or a mouse = hover action to perform.

So a fixture looks like:

def fixture =3D {
=  =E2=80=9Cfield1=E2=80=9D: =E2=80=9Cvalue1=E2=80=9D,
=  =E2=80=9Cfield2=E2=80=9D: =E2=80=9Cvalue2=E2=80=9D,
=  =E2=80=9C_CLOSURE_0=E2=80=9D: = {\$(=E2=80=98a.button=E2=80=99).click()},
=  =E2=80=9Cfield3=E2=80=9D: =E2=80=9Cvalue3=E2=80=9D,
=  =E2=80=9C_CLOSURE_1=E2=80=9D: {=E2=80=A6}
}

So the two points you make about = GStrings (which I appreciate), don=E2=80=99t apply here.  The = =E2=80=9C_CLOSURE_\${c++}=E2=80=9D GString is just a way to uniquify the = closure keys automatically.

It is a = bit ugly, but it is also concise (it is essentially a script that is run = through an interpreter).  Could a different data structure do the trick? =  Sure:

def = fixture =3D [
[=E2=80=9Cfield1=E2=80=9D,= =E2=80=9Cvalue1=E2=80=9D],
=  [=E2=80=9Cfield2=E2=80=9D, =E2=80=9Cvalue2=E2=80=9D],
[{\$(=E2=80=98a.button=E2=80=99).click()}],
=E2=80=A6
];

Just a little too = brackety in my opinion, but it does dispense with the ugly = =E2=80=9C_CLOSURE_\${c++}=E2=80=9D naming.

What I was hoping for was a = generator-like function that I could use in place of the = =E2=80=9C_CLOSURE_\${c++}=E2=80=9D, but Groovy doesn=E2=80=99t seem to = allow method execution when defining a map key (though GStrings come = close).

=E2=80=94= Jeff

On Jul 22, 2015, at 10:49 PM, Jochen Theodorou <blackdrag@gmx.org> = wrote:

Am = 23.07.2015 00:39, schrieb Lowery, Jeff:
Trying to find the simplest way to auto = generate a map key; the best
I've come up with is:

def c=3D0

def map = =3D {
"_KEY\$c++" : "foo", "_KEY\$c++": = "bar", ... }

First of all: You = shall not use GString as map key.
a) GString is a mutable, = using mutables as map keys can lead to very interesting behaviour of the = map
b) GString is not having the same hashcode as String = even if the toString() representation is the same.

Factor (a) is probably not a problem here, but (b) can easily = cause a problem.

Is there better?

you = are not really giving enough information. For example, why not simply = use a list here? The key seems not to play an important role, thus I = doubt that searching is the problem you try to solve with the map. But = then it is questionable if a map is even the right datastructure for = your problem.

bye = blackdrag

--
Jochen = "blackdrag" Theodorou
blog: http://blackdragsview.blogspot.com/

= --Apple-Mail=_F7554A37-7C38-41E6-A5B4-354B84EAF218--