Guava: Provide an Optional.transformAndConcat

[gissuebot]

_Original issue created by dale.wijnand on 2013-06-17 at 10:52 AM_

---

I sometimes find myself with an optional that I want to transform, calling a method that returns an Optional.

It would be nice if there were a transformAndConcat for Optional as well, so my Optional<A> is transformed into an Optional<B> not an Optional<Optional<B>>.

[gissuebot]

_Original comment posted by kurt.kluever on 2013-06-17 at 04:46 PM_

---

Does Optional#presentInstances do the trick for you?

---

Labels: Type-Addition, Package-Base

[gissuebot]

_Original comment posted by kurt.kluever on 2013-06-17 at 04:46 PM_

---

Does Optional#presentInstances do the trick for you?

[gissuebot]

_Original comment posted by dale.wijnand on 2013-06-17 at 06:03 PM_

---

Not really, as in, only if I really stretch it:

Iterables.tryFind(Optional.presentInstances(optional.transform(function).asSet()), Predicates.alwaysTrue())

Would be nice to just do:

optional.transformAndConcat(function)

(or flatmap, but that breaks the current convention :D)

[gissuebot]

_Original comment posted by dale.wijnand on 2013-06-17 at 06:10 PM_

---

One take of the implementation is something like this: https://gist.github.com/dwijnand/5798899

[gissuebot]

_Original comment posted by [email protected] on 2013-06-17 at 06:30 PM_

---

It sounds like you're asking for what some people would call the monadic bind?

[gissuebot]

_Original comment posted by dale.wijnand on 2013-06-17 at 07:56 PM_

---

Yes

[gissuebot]

_Original comment posted by kelseyfrancis on 2013-08-28 at 11:15 PM_

---

This method would be very useful. It seems like a trivial implementation on Optional<T> is:

<V> Optional<V> transformAndConcat(Function<? super T, Optional<V>> function) {
    return transform(function).or(Optional.<V>absent());
}

[TomRK1089]

I was looking for this today and was quite surprised it isn't present. Using or() after transform() is sufficient, but it would be a nice addition to the standard.

[agentgt]

I'm actually wondering why this hasn't been fixed already given that Java 8 is out.

According to the mailing list the issue was Java didn't have lambdas and thus it was awkward.

With RxJava and various other monadic style libraries I have gotten used to "staying in the monad". It is such a trivial change. I hope it gets in soon.

[technoir42]

Would you accept a PR implementing this?

[jbduncan]

I would consider this "fixed" now that com.google.common.base.Optional.toJavaUtil().flatMap(...) exists...

[technoir42]

We need it on Android. Our minSdkVersion is 16 so we can't use java.util.Optional yet and won't be able to for several years.

[lowasser]

On Android, wouldn't you want to avoid the allocations caused by the
anonymous inner class and by Optional itself?

On Thu, Mar 9, 2017, 8:37 AM Sergey [e-mail] wrote:

We need it on Android. Our minSdkVersion is 16 so we can't use
java.util.Optional yet and won't be able to for several years.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/google/guava/issues/1450#issuecomment-285352848, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AAhPOer0vTeQilh4nVKrS9OLOE_JiB8Oks5rkACEgaJpZM4C1jO5
.

[jbduncan]

@zergtmn On a sort of side note, if all else fails, then there at least exists Atlassian Fugue 2.x, which is Java 1.6 compatible and provides an Option type which works a bit differently to Java 8's or Guava's Optional, but otherwise has higher order functions like flapMap.

[agentgt]

On a tangental note I didn't know toJavaUtil was added. I am curious how v22 is going to backport to JDK6 with the JDK8 reference.

Are there going to be two jars?

That is going to be interesting dealing with dependency management of that. If possible maybe make a new namespace or something? Maybe com.google.common8 or something. This is probably discussed on the mailing list but my embarrassingly lazy googling did not find anything.

EDIT Ah I see how as it was done with JDK5. Artifact rename and then I guess if you depend on some other project you just exclude the JDK6 dependency (or do provided in maven parlance).

[kevinb9n]

(My teammates understand this better than I and may correct me.)

On Thu, Mar 9, 2017 at 12:48 PM, Adam Gent [e-mail] wrote:

On a tangental note I didn't know toJavaUtil was added. I am curious how
v22 is going to backport to JDK6 with the JDK8 reference.

Such methods don't get added to the backport.

Are there going to be two jars?
>
Yes, two distinct artifacts.

That is going to be interesting dealing with dependency management of
that. If possible maybe make a new namespace or something? Maybe
com.google.common8 or something.

Any library (i.e., a jar that will get used on classpaths outside its own
control) that depends on Guava and wants to serve both Java 8+ users and
Java 7- users will have to publish two parallel artifacts just as we do.
This is a little annoying, but the separate namespace would make things a
lot worse.

If they want to actually use Guava features that aren't present in the
backport, they'll have to go further and fork their codebase (again, just
as we do). But such features should only be Java8-specific ones (we think),
which would have forced that fork anyway.

--
Kevin Bourrillion | Java Librarian | Google, Inc. | [email protected]

[cpovirk]

Any library (i.e., a jar that will get used on classpaths outside its own
control) that depends on Guava and wants to serve both Java 8+ users and
Java 7- users will have to publish two parallel artifacts just as we do.

I'm not sure if we're decided yet whether to recommend that others release parallel artifacts or whether to recommend that they release a single version that depends on the backport, asking users to substitute the mainline if desired. @netdpb should know.

[cpovirk]

Kevin recently said:

I'm sorry, but the legacy Optional class is indeed frozen.

I'm closing this and any other Optional feature requests I see floating around.