Nulls
Joe Bowbeer
joe.bowbeer at gmail.com
Fri Sep 21 15:03:33 PDT 2012
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
>
More information about the lambda-libs-spec-observers
mailing list