Nulls

[Tim Peierls]

Yes, I know of these other types. But the Guava Optional javadocs read, in
part:

This class is not intended as a direct analogue of any existing "option" or
"maybe" construct from other programming environments, though it may bear
some similarities.

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.

--tim

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.
>
>
>
> http://james-iry.blogspot.com/2010/08/why-scalas-and-haskells-types-will-save.html
>
> Joe
>
> 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.
>> Optional.fromNullable(nullable),
>> 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
>> Optional.
>>
>> --tim
>>
>
>