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 <blackd...@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/
>
