[
https://issues.apache.org/jira/browse/GROOVY-10223?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17422401#comment-17422401
]
Stephen Smith edited comment on GROOVY-10223 at 9/29/21, 9:34 PM:
------------------------------------------------------------------
Thanks [~paulk] for asking.
My perception of the situation in Java is that Optional is meant to be
important for both noting the existence of the wrapped value and the absence of
the value. It's an alternative for returning {{null}} from a method where
{{null}} contains information regarding the absence of returned information.
Optional can also be used as a carrier of information that's only important if
it exists.
{code:groovy}
def isBiggerThanTwo = optional.any {
it > 2
}
{code}
or you want to process the information if it exists and collect the results,
but an empty list is perfectly valid as a result:
{code:groovy}
def processedList = [ ... ]
processedList += optional.collect {
process( it )
}
{code}
It opens up all of the list processing abilities of the language to something
that should have been iterable to begin with (and as Java has added
{{.stream()}} to Optional, they recognize the value of using it for mapping and
filtering)
It also opens up the possibility of using Groovy Truth on an Optional, because
if it can be converted to a collection, then an empty collection indicates
false:
{code:groovy}
if (optional) {
// do something
}
{code}
There are many reasons why languages like Scala prefer viewing Option as an
iterable rather than as an value subject to imperative evaluation:
[https://stackoverflow.com/questions/6819373/why-is-foreach-better-than-get-for-scala-options/6820001|https://stackoverflow.com/questions/6819373/why-is-foreach-better-than-get-for-scala-options/6820001]
[http://blog.tmorris.net/posts/scalaoption-cheat-sheet/|http://blog.tmorris.net/posts/scalaoption-cheat-sheet]
was (Author: stephenns):
Thanks [~paulk] for asking.
My perception of the situation in Java is that Optional is meant to be
important for both noting the existence of the wrapped value and the absence of
the value. It's an alternative for returning {{null}} from a method where
{{null}} contains information regarding the absence of returned information.
Optional can also be used as a carrier of information that's only important if
it exists.
{code:groovy}
def isBiggerThanTwo = optional.any {
it > 2
}
{code}
or you want to process the information if it exists and collect the results,
but an empty list is perfectly valid as a result:
{code:groovy}
def processedList = [ ... ]
processedList += optional.collect {
process( it )
}
{code}
It opens up all of the list processing abilities of the language to something
that should have been iterable to begin with (and as Java has added
{{.stream()}} to Optional, they recognize the value of using it for mapping and
filtering)
It also opens up the possibility of using Groovy Truth on an Optional, because
if it can be converted to a collection, then an empty collection indicates
false:
{code:groovy}
if (optional) {
// do something
}
{code}
There are many reasons why languages like Scala prefer viewing Option as an
iterable rather than as an value subject to imperative evaluation:
[https://stackoverflow.com/questions/6819373/why-is-foreach-better-than-get-for-scala-options/6820001|http://example.com/]
[http://blog.tmorris.net/posts/scalaoption-cheat-sheet/|http://example.com/]
> Add support for Optional to DefaultTypeTransformation.asCollection()
> --------------------------------------------------------------------
>
> Key: GROOVY-10223
> URL: https://issues.apache.org/jira/browse/GROOVY-10223
> Project: Groovy
> Issue Type: New Feature
> Components: groovy-jdk
> Reporter: Stephen Smith
> Priority: Trivial
> Labels: features
>
> The JDK recently added support for *Optional::stream()* which returns a
> stream containing either the unwrapped value or an empty stream if the
> *Optional* is empty.
> In the groovy-jdk, using iteration however will call
> {noformat}
> DefaultTypeTransformation.asCollection(){noformat}
> which does not specifically check for type *Optional*, instead it will just
> wrap the *Optional* itself in a *List* rather than the unwrapped value as the
> default behavior.
> Adding an _if else_ clause will allow using the Optional as either a single
> or empty list.
> {code:java}
> if (value instanceOf Optional) {
> return ((Optional)value).map(List::of).orElse(List.of())
> }{code}
> Alternatively, add an *asList()* to the Optional class.
> (edit: 2021-09-13, missing bracket in code example)
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
