[
https://issues.apache.org/jira/browse/GROOVY-10863?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Paul King updated GROOVY-10863:
-------------------------------
Description:
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.
> 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)