Option[T] and null

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
10 messages Options
Reply | Threaded
Open this post in threaded view
|

Option[T] and null

Paul Phillips-3
I wonder what is the current thinking regarding Some(null).  When I discovered this was allowed I recoiled in horror,
but it's hard to argue with the difficulty that if List.find (for instance) returns an Option and a list can contain
nulls, disallowing Some(null) pretty much breaks the interface.

That particular example is problematic only because Option is overloaded with at least two meanings in common use: as
an all-purpose replacement for null ("this variable may or may not have a legal value right now") and to layer a
boolean on top of an arbitrary value ("the answer to your question is either yes or no, and if yes, take this too.")
Then of course there are the multiple uses for null further complicating the matter (unassigned, various forms of
failure, end of sequence, I shudder to imagine how many others.)

So while Option[T] is a tolerable replacement for null in some circumstances, it's a long ways from ideal.  I am sure
some people have thought about this in more detail.  If the two uses I named above were separated into distinct
containers (Option[T] and Maybe[T], say) could Some(null) then be disallowed without breaking a lot of code? Are there
many more difficulties lying in wait?

I just think it'd be keen to reach a place where I could stop sweating when I need to defensively program around the
appearance of null without having to introduce noisy new syntax.  I imagine being able to interoperate with null-heavy
code from behind a wall beyond which null cannot penetrate.

--
Paul Phillips      | Simplicity and elegance are unpopular because
Future Perfect     | they require hard work and discipline to achieve
Empiricist         | and education to be appreciated.
all hip pupils!    |     -- Dijkstra
Reply | Threaded
Open this post in threaded view
|

Re: Option[T] and null

Ricky Clarkson
Why can a list contain nulls?  Can this be changed?  If this was changed would it be reasonable to disallow Some(null), or are there other gotchas?

I've never seen your second meaning of Option; where can I find an example of that in code?

I object to having both Option and Maybe, purely on the grounds that it's hard enough to remember which one's which in each language, nevermind having both in one language.

2008/12/5 Paul Phillips <[hidden email]>
I wonder what is the current thinking regarding Some(null).  When I discovered this was allowed I recoiled in horror,
but it's hard to argue with the difficulty that if List.find (for instance) returns an Option and a list can contain
nulls, disallowing Some(null) pretty much breaks the interface.

That particular example is problematic only because Option is overloaded with at least two meanings in common use: as
an all-purpose replacement for null ("this variable may or may not have a legal value right now") and to layer a
boolean on top of an arbitrary value ("the answer to your question is either yes or no, and if yes, take this too.")
Then of course there are the multiple uses for null further complicating the matter (unassigned, various forms of
failure, end of sequence, I shudder to imagine how many others.)

So while Option[T] is a tolerable replacement for null in some circumstances, it's a long ways from ideal.  I am sure
some people have thought about this in more detail.  If the two uses I named above were separated into distinct
containers (Option[T] and Maybe[T], say) could Some(null) then be disallowed without breaking a lot of code? Are there
many more difficulties lying in wait?

I just think it'd be keen to reach a place where I could stop sweating when I need to defensively program around the
appearance of null without having to introduce noisy new syntax.  I imagine being able to interoperate with null-heavy
code from behind a wall beyond which null cannot penetrate.

--
Paul Phillips      | Simplicity and elegance are unpopular because
Future Perfect     | they require hard work and discipline to achieve
Empiricist         | and education to be appreciated.
all hip pupils!    |     -- Dijkstra

Reply | Threaded
Open this post in threaded view
|

Option[T] and null

Szymon Jachim
Shouldn't Some(null) == None ?

On Fri, Dec 5, 2008 at 5:49 PM, Ricky Clarkson <[hidden email]> wrote:
Why can a list contain nulls?  Can this be changed?  If this was changed would it be reasonable to disallow Some(null), or are there other gotchas?

I've never seen your second meaning of Option; where can I find an example of that in code?

I object to having both Option and Maybe, purely on the grounds that it's hard enough to remember which one's which in each language, nevermind having both in one language.

2008/12/5 Paul Phillips <[hidden email]>

I wonder what is the current thinking regarding Some(null).  When I discovered this was allowed I recoiled in horror,
but it's hard to argue with the difficulty that if List.find (for instance) returns an Option and a list can contain
nulls, disallowing Some(null) pretty much breaks the interface.

That particular example is problematic only because Option is overloaded with at least two meanings in common use: as
an all-purpose replacement for null ("this variable may or may not have a legal value right now") and to layer a
boolean on top of an arbitrary value ("the answer to your question is either yes or no, and if yes, take this too.")
Then of course there are the multiple uses for null further complicating the matter (unassigned, various forms of
failure, end of sequence, I shudder to imagine how many others.)

So while Option[T] is a tolerable replacement for null in some circumstances, it's a long ways from ideal.  I am sure
some people have thought about this in more detail.  If the two uses I named above were separated into distinct
containers (Option[T] and Maybe[T], say) could Some(null) then be disallowed without breaking a lot of code? Are there
many more difficulties lying in wait?

I just think it'd be keen to reach a place where I could stop sweating when I need to defensively program around the
appearance of null without having to introduce noisy new syntax.  I imagine being able to interoperate with null-heavy
code from behind a wall beyond which null cannot penetrate.

--
Paul Phillips      | Simplicity and elegance are unpopular because
Future Perfect     | they require hard work and discipline to achieve
Empiricist         | and education to be appreciated.
all hip pupils!    |     -- Dijkstra



Reply | Threaded
Open this post in threaded view
|

Re: Option[T] and null

Ismael Juma
Szymon Jachim <sjachim <at> gmail.com> writes:
> Shouldn't Some(null) == None ?

That is one interpretation. Some people disagree though.
Note that this has been discussed at least twice before:

http://www.nabble.com/Option-asserts-that-its-argument-is-not-null-td17152322.html

http://www.nabble.com/Some(null)-td14583480.html

Ismael

Reply | Threaded
Open this post in threaded view
|

Re: Re: Option[T] and null

Jan Lohre
For consistency I would say Some(null) should be disallowed (I think it actually was in a version in trunk, followed by some discussion). For being compatible disallowing it now is no option.

Cheers,
Jan

2008/12/5 Ismael Juma <[hidden email]>
Szymon Jachim <sjachim <at> gmail.com> writes:
> Shouldn't Some(null) == None ?

That is one interpretation. Some people disagree though.
Note that this has been discussed at least twice before:

http://www.nabble.com/Option-asserts-that-its-argument-is-not-null-td17152322.html

http://www.nabble.com/Some(null)-td14583480.html

Ismael


Reply | Threaded
Open this post in threaded view
|

Re: Re: Option[T] and null

Ricky Clarkson
There are more important things than backward compatibility.

2008/12/5 Jan Lohre <[hidden email]>
For consistency I would say Some(null) should be disallowed (I think it actually was in a version in trunk, followed by some discussion). For being compatible disallowing it now is no option.

Cheers,
Jan

2008/12/5 Ismael Juma <[hidden email]>

Szymon Jachim <sjachim <at> gmail.com> writes:
> Shouldn't Some(null) == None ?

That is one interpretation. Some people disagree though.
Note that this has been discussed at least twice before:

http://www.nabble.com/Option-asserts-that-its-argument-is-not-null-td17152322.html

http://www.nabble.com/Some(null)-td14583480.html

Ismael



Reply | Threaded
Open this post in threaded view
|

Re: Re: Option[T] and null

Jan Lohre
I am actually tired of this discussion.

2008/12/5 Ricky Clarkson <[hidden email]>
There are more important things than backward compatibility.

2008/12/5 Jan Lohre <[hidden email]>

For consistency I would say Some(null) should be disallowed (I think it actually was in a version in trunk, followed by some discussion). For being compatible disallowing it now is no option.

Cheers,
Jan

2008/12/5 Ismael Juma <[hidden email]>

Szymon Jachim <sjachim <at> gmail.com> writes:
> Shouldn't Some(null) == None ?

That is one interpretation. Some people disagree though.
Note that this has been discussed at least twice before:

http://www.nabble.com/Option-asserts-that-its-argument-is-not-null-td17152322.html

http://www.nabble.com/Some(null)-td14583480.html

Ismael




Reply | Threaded
Open this post in threaded view
|

Re: Option[T] and null

mbeckerle-2
In reply to this post by Paul Phillips-3
Seems to me there are two things being mixed here in Scala and we should consider whether they should be separated.

Being relatively new to scala, there's probably a thread about this already, so just point me there. (Googling "scala language nice option" didn't get me enough quality discussion.)

1) Java compatibiliity - dealing with nulls coming back from java, and passing nulls to java. Coping with them somehow where null can be a legitimate value. Allowing Some(null) makes sense here.

2) Using the type system to avoid "null pointer" exceptions - or the moral equivalent - which I believe would be knowing that an Option-like type is Some(...) not None.  Here, allowing Some(null) is anathema. One would prefer a constructor for Some(...) that rejects null, ideally at the type-check level, not a runtime check.

Has the non-nullable types mechanism of the Nice language been examined (and dispensed with?) before? It seems that it addresses these in a much more concise way. Notationally Scala would need to do something different, but the concept that there is a type-system distinction between non-nullable String, and potentially null String seems very powerful for making programs simpler.

When I look at the Scala type diagram, it looks like Null sits at the bottom (above Nothing). It seems like one should be able to express a type T where T :> Null   (did I use the right symbol there? I mean T stronger than Null), but the java types like java.lang.String are positioned above Null, yet something which returns java.lang.String can return null, so java.lang.String really behaves like a type union of Null and non-nullable String.  
Reply | Threaded
Open this post in threaded view
|

Re: Option[T] and null

James Iry-2


On Wed, Dec 10, 2008 at 6:19 AM, mbeckerle <[hidden email]> wrote:



Has the non-nullable types mechanism of the Nice language been examined (and
dispensed with?) before? It seems that it addresses these in a much more
concise way. Notationally Scala would need to do something different, but
the concept that there is a type-system distinction between non-nullable
String, and potentially null String seems very powerful for making programs
simpler.
 
Not quite Nice, but an alternative where Nullable is a magic trait has been considered:
http://www.nabble.com/Some(null)-td14583480.html
 

When I look at the Scala type diagram, it looks like Null sits at the bottom
(above Nothing).

Exactly, Null is a subtype of all of AnyRef's subtypes.  Notationally,

forall T . T <: AnyRef <=> T >: Null
 
"for all T, if and only if T is a subtype of AnyRef then T is a supertype of Null"

That's in keeping with Java, but there you replace the type "AnyRef" with "Object" and Null isn't a denotable type but none-the-less limited by the fact that you can't use null where a "primitive" type is expected.
Reply | Threaded
Open this post in threaded view
|

Re: Option[T] and null

Viktor Klang


On Wed, Dec 10, 2008 at 4:17 PM, James Iry <[hidden email]> wrote:


On Wed, Dec 10, 2008 at 6:19 AM, mbeckerle <[hidden email]> wrote:



Has the non-nullable types mechanism of the Nice language been examined (and
dispensed with?) before? It seems that it addresses these in a much more
concise way. Notationally Scala would need to do something different, but
the concept that there is a type-system distinction between non-nullable
String, and potentially null String seems very powerful for making programs
simpler.
 
Not quite Nice, but an alternative where Nullable is a magic trait has been considered:

When I look at the Scala type diagram, it looks like Null sits at the bottom
(above Nothing).

Exactly, Null is a subtype of all of AnyRef's subtypes.  Notationally,

forall T . T <: AnyRef <=> T >: Null
 
"for all T, if and only if T is a subtype of AnyRef then T is a supertype of Null"

null.type is what?
 


That's in keeping with Java, but there you replace the type "AnyRef" with "Object" and Null isn't a denotable type but none-the-less limited by the fact that you can't use null where a "primitive" type is expected.



--
Viktor Klang
Senior Systems Analyst