[
https://issues.apache.org/jira/browse/GROOVY-10863?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17645859#comment-17645859
]
Paul King commented on GROOVY-10863:
------------------------------------
What I originally had in mind was a shorthand for {{collect}} and {{join}}
which is what the Eclipse Collections {{makeString}} does. So like we have:
{code}
assert 30 == [1, 2, 3, 4].sum{ i -> i**2 }
{code}
as a shorthand for:
{code}
assert 30 == [1, 2, 3, 4].collect{ i -> i**2 }.sum()
{code}
So, I was thinking:
{code}
assert '1, 4, 9, 16' == [1, 2, 3, 4].join(', '){ i -> i**2 }
{code}
as a shorthand for:
{code}
assert '1, 4, 9, 16' == [1, 2, 3, 4].collect{ i -> i**2 }.join(', ')
{code}
If we also supported the start and end (prefix and suffix) delimiters (as per
{{makeString}} in Eclipse Collections) then we'd have:
{code}
def months = [thanksgiving, xmas, newyears]
assert '(Nov, Dec, Jan)' == months.join(', ', '(', ')') { m -> m.format('MMM')
}
{code}
as a shorthand for:
{code}
assert '(Nov, Dec, Jan)' == '(' + months.collect { m -> m.format('MMM')
}.join(', ') + ')'
{code}
> Provide some additional Closure join variants
> ---------------------------------------------
>
> Key: GROOVY-10863
> URL: https://issues.apache.org/jira/browse/GROOVY-10863
> Project: Groovy
> Issue Type: Improvement
> Reporter: Paul King
> Priority: Major
>
> The idea (initiated on Slack) is to add in some join variants which take a
> Closure which does an additional transformation during join processing.
> Two possible implementations are:
> * the transform is essentially a "collect" on each element before traditional
> joining happens with some supplied delimiter - this is similar to what we do
> in other cases like the "sum" variant with a Closure and also what makeString
> in Eclipse Collections does
> * the transform embodies the whole join aspect, essentially becoming an
> inject and replacing the supplied delimiter
> We could support variants for both depending on whether the delimiter
> parameter was present.
> Other variations are whether start/end (or prefix/suffix) parameters would be
> supplied and potentially also direction (think foldl vs foldr).
> If we end up wanting to support all variations, we could provide a named
> parameter (map) version of the method.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
