[ 
https://issues.apache.org/jira/browse/GROOVY-10863?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17645860#comment-17645860
 ] 

Paul King edited comment on GROOVY-10863 at 12/11/22 10:51 PM:
---------------------------------------------------------------

Now, all of these have an implicit fold/reduce occurring: 
{code}
{ a, b -> a.toString() + delimiter + b.toString() }
{code}
Guillaume's idea was to potentially allow customising that operation too. In 
further discussions, he seems reasonably happy with just using {{inject}} for 
that use case.


was (Author: paulk):
Now, all of these have an implicit fold/reduce occurring: {{\{a, b -> 
a.toString() + delimiter + b.toString() \}}}
Guillaume's idea was to potentially allow customising that operation too. In 
further discussions, he seems reasonably happy with just using {{inject}} for 
that use case.

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

Reply via email to