This is sort of a unique situation, where I’m setting up test fixtures and trying to minimize the punctuation. The fixture is iterated through, and in general the key is the name of a form field and the value is the value the field is set to.  

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 = {
     “field1”: “value1”,
     “field2”: “value2”,
     “_CLOSURE_0”: {$(‘a.button’).click()},
     “field3”: “value3”,
     “_CLOSURE_1”: {…}
}

So the two points you make about GStrings (which I appreciate), don’t apply here.  The “_CLOSURE_${c++}” 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 = [
   [“field1”, “value1”],
   [“field2”, “value2”],
   [{$(‘a.button’).click()}],
   …
];

Just a little too brackety in my opinion, but it does dispense with the ugly “_CLOSURE_${c++}” naming.

What I was hoping for was a generator-like function that I could use in place of the “_CLOSURE_${c++}”, but Groovy doesn’t seem to allow method execution when defining a map key (though GStrings come close).

— 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=0
>> 
>> def map = {
>>    "_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/
>