tim at peierls.net
Fri Sep 21 15:47:17 PDT 2012
Yes, I know of these other types. But the Guava Optional javadocs read, in
This class is not intended as a direct analogue of any existing "option" or
"maybe" construct from other programming environments, though it may bear
It is this class that I have been using for a year and that I think ought
to be made a standard class in Java, pretty much as is. It has paid back in
spades the extremely small investment needed to learn it.
On Fri, Sep 21, 2012 at 6:03 PM, Joe Bowbeer <joe.bowbeer at gmail.com> wrote:
> The Option type reportedly originated in the last millennium in ML, and
> has been used in Haskell (as Maybe), and several other languages.
> null exists in Scala for interoperability with existing Java code, and it
> is possible, though rare in Scala, to create a Some(null), which I think
> would be the moral equivalent of Optional(null). The AnyRef type in Scala
> is essentially Object in Java, and therefore an Option[AnyRef] can hold a
> Some(null) value.
> Btw, I think this snippet from James Iry's blog is relevant:
> For interoperability reasons Scala has a full blown Java-like null. But
>> the experience that all the Scala developers I know have is that NPE is
>> mostly only a problem when dealing with existing Java libraries because
>> Scala programmers and libraries avoid it. Plus, Scala's "Option(foo)"
>> promotes foo to either Some(foo) or None depending on whether it's null or
>> not that at least enables the map/flatMap style of "safe invoke." It's far
>> less than perfect, but about the best that can be done when dealing
>> directly with Java.
> On Fri, Sep 21, 2012 at 11:26 AM, Tim Peierls <tim at peierls.net> wrote:
>> On Fri, Sep 21, 2012 at 2:04 PM, Joe Bowbeer <joe.bowbeer at gmail.com>wrote:
>>> On Fri, Sep 21, 2012 at 9:25 AM, Brian Goetz wrote:
>>>> I think the "if we don't support it people won't adopt lambda" is way,
>>>> way overstated. Its a factor to consider, nothing more.
>> It never occured to me that Optional was being proposed as a sop to
>> lambda users. I've been using Guava's version of Optional for about a year,
>> in Java 6 without any thought of lambdas.
>>> I think there is a strong usability case for supporting nulls. I see it
>>> this way:
>>> Q: How many Java methods return null?
>>> A: Countless many, and there is no type-system in place to indicate when
>>> they do or don't
>>> Q: What will lamda users want to do?
>>> A: Apply their methods and collect the results; perform parallel
>>> reduction, stream them, etc.
>>> We will either need to force these lambda users to create Optional-like
>>> adapters for all of their sources of null in the world,
>> Seems like a few standard adapters would help a lot.
>> Collection.fromNullable(collectionWithNulls), etc.
>>> or we will need to support the most common use cases without throwing
>>> exceptions. I don't like the first option for lambda initiates because it
>>> presents them with a hurdle right away.
>> Maybe there are some very common usages that should be tolerated, but if
>> everything is tolerated, no one will ever change, and people will continue
>> to write APIs that return null, and users will continue not to test for
>> null, and an opportunity to improve things will have been missed.
>>> I'm undecided whether Optional is of any use in the bigger design
>>> effort. I'm certain they won't be as useful as they are in Scala, because
>>> the absence of Optional doesn't mean anything in Java -- whereas the
>>> absence in Scala can mean no NPE. In any event, Optional should be
>>> subservient to the bigger design effort.
>> I had forgotten that Scala has an Optional. The Optional I use is *not *Scala's
More information about the lambda-libs-spec-observers