[
https://issues.apache.org/jira/browse/GROOVY-11146?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17750792#comment-17750792
]
ASF GitHub Bot commented on GROOVY-11146:
-----------------------------------------
eric-milles commented on PR #1926:
URL: https://github.com/apache/groovy/pull/1926#issuecomment-1664170619
The changes to the plain `flatten` seem fine. The changes to the closure
variant I'm thinking about. Should you say Array, Collection and Optional
handled internally and all else goes to the closure? If the closure can bear
optionals, then you lose all guarantees of it returning `? extends T`.
```java
public static <T> Collection<T> flatten(Iterable<T> self, Closure<? extends
T> flattenUsing) {
// ^^^
^^^^^^^^^^^^^
```
> Consider supporting flattening of Optionals in flatten/collectMany
> ------------------------------------------------------------------
>
> Key: GROOVY-11146
> URL: https://issues.apache.org/jira/browse/GROOVY-11146
> Project: Groovy
> Issue Type: Improvement
> Reporter: Paul King
> Assignee: Paul King
> Priority: Major
>
> The functional idiom of map/collect then flatten is so common that we
> normally have a shorthand for combining them: flatMap, bind, collectMany.
> We have that for streams (piggybacking on Java) and collections but not
> optionals.
> {code}
> var items = ["1", "2", "foo", "3", "bar"]
> var toInt1 = s -> s.number ? Stream.of(s.toInteger()) : Stream.empty()
> println items.stream().flatMap(toInt1).toList()
> var toInt2 = s -> s.number ? [s.toInteger()] : []
> println items.collectMany(toInt2)
> var toInt3 = s -> s.number ? Optional.of(s.toInteger()) : Optional.empty()
> println items.collect(toInt3).flatten{ it -> it.orElse([]) }
> println items.collect(toInt3).findResults{ it -> it.orElse(null) }
> println items.collect(toInt3).grep()*.get()
> {code}
> This issue will explore options for adding that.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
