groovy-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeff Lowery <>
Subject Re: Auto-generating a map key
Date Thu, 23 Jul 2015 17:31:47 GMT
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”],

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

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 <> 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:

View raw message