Java's Optional gets filter, map and flatMap

[Morten A-Gott]

With a the other day, Java 8's Optional is starting to look more
useful. It finally got filter, map and flatMap:
http://hg.openjdk.java.net/lambda/lambda/jdk/rev/fde3666e6394

Then, ifPresent was renamed to forEach:
http://hg.openjdk.java.net/lambda/lambda/jdk/rev/9d9753590439

Now, if we could get an factory method that will handle instansiation
with nulls, (like a fromNullable in guava, or the apply in Option in
Scala) creating Optionals would be a lot less verbose. No reason why
every developer should have to write a null check before creating an
Optional.

And while they are at it, why not add 'exists' and 'forall' ?

[Jan Goyvaerts]

Don't push your luck ! :-p

--
You received this message because you are subscribed to the Google Groups "Java Posse" group.
To unsubscribe from this group and stop receiving emails from it, send an email to javaposse+...@googlegroups.com.
To post to this group, send email to java...@googlegroups.com.
Visit this group at http://groups.google.com/group/javaposse?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

[clay]

Wow! Nice!

I'm surprised it got added so quietly after such extensive debate, and months after everyone gave up asking. I'm definitely not complaining.

Yes, a JDK8 standard equivalent to guava fromNullable or fj fromNull would be nice as well. I can live with what they have though.

[clay]

What do you want in "exists" and "forAll" that can't be done with the current "isPresent" and "forEach"?

[Ricky Clarkson]

Well, lambdas started getting added after everyone gave up asking too. :)

[Cédric Beust ♔]

Okay everyone, nobody talk about Jigsaw, starting now.

-- 

Cédric

[Kevin Wright]

Is it too soon to remain *absolutely silent* about comprehensions, pattern matching, and pretty much any proposal that John Rose has ever come up with?

Kevin Wright
mail: kevin....@scalatechnology.com
gtalk / msn : kev.lee...@gmail.com

quora: http://www.quora.com/Kevin-Wright

google+: http://gplus.to/thecoda

twitter: @thecoda

vibe / skype: kev.lee.wright

steam: kev_lee_wright

"My point today is that, if we wish to count lines of code, we should not regard them as "lines produced" but as "lines spent": the current conventional wisdom is so foolish as to book that count on the wrong side of the ledger" ~ Dijkstra

[Morten A-Gott]

On Tuesday, June 4, 2013 7:56:24 PM UTC+2, clay wrote:

What do you want in "exists" and "forAll" that can't be done with the current "isPresent" and "forEach"?

First of all, to achieve anything similar with isPresent/forEach (isPresent is now called forEach) you have to code with side effects (it takes a lambda with a void return type), where the lambda you pass in have to mutate a boolean variable or something similar. It will be more code, and more error prone.

Second, the exists and forAll has different meanings, depending on whether you have a some or a none, for example:

Some(1).forAll(i -> i%2 == 0) returns false

Some(1).exists(i -> i%2 == 0) return false

Some(2).forall(i -> i%2 == 0) returns true

Some(2).exists(i -> i%2 == 0) return true

None.exists(i -> i%2 == 0) returns false

None.forall(i -> i%2 == 0) returns true

It is nice to have when doing validation for example, where you allow a field to be unset, but if it is set, it has to follow a certain rule, or the opposite, where you require something to be be Some (in one context) and validate according to a method. Let's say you have a Customer object, where the e-mail is Optional, but if it is some, then you want it to be a valid e-mail (good use case for forall). The same Customer object might have a phone number, which is mandatory, but represented by a Optional, as your legacy customer db don't have telephone numbers for all customers (good use case for exists).