7 ms·

> Indeed, Option in Scala has the same problem eh? scala> val safe = Option(null) safe: Option[Null] = None

by virtualwhys 12y ago

adamwbarr 12y ago
scala> val x = Some(null) x: Some[Null] = Some(null)
- virtualwhys 12y ago
  That's pretty contrived, when would you _ever_ wrap a thing that could be null in a Some? Even so, to continue with your example: scala> x foreach println null x.get res2: Null = null Hey, what do you know, no NPE. Try harder ;-)
  - adamwbarr 12y ago
    Ok fair point re it being contrived! Although (having just re-read it), the original post's complaint was actually that: > the compiler (afaik) doesn't prevent you from setting an Optional field to null ie scala> val option: Option[Any] = null option: Option[Any] = null
    - the_af 12y ago
      Exactly, that was my complaint. It makes elegant pattern matching against Option types (the whole point of using them, in fact) less than useful. Now, in Scala-land, you have to check that they aren't null, which sucks.
      - frowaway001 12y ago
        This complaint shows pretty well that some people have never actually used Scala.
        the_af 12y ago
        Can you elaborate? The whole point of Option types is that I can map (for example) over them without explicitly checking what their value is, and it will work without a runtime error. Same with pattern matching. With the introduction of null, this is no longer possible. I've just shown an example of getting an NPE while mapping over an Option[String]. Now we're back in Java-land, where I must explicitly check for nulls, read the source code of every method or trust some comment that tells me that it will never return null. (Ok, not exactly like Java-land: a Scala programmer who returns a null for a function with type Option is very inexperienced or is doing something naughty. But why does the language even allow it?) Aside from telling me I'm wrong, can you explain why?
        roryokane 12y ago
        Scala needed to support null somehow in order to interoperate with arbitrary Java code, such as passing null as a parameter to a third-party Java library. So at least some variables should be allowed to have null. Maybe they couldn’t think of a way to prevent Option-typed variables from being null without preventing arbitrary Java interop. Making only Option types reject nulls might have been thought too hacky. Those are just my guesses of the design rationale, working from the fact that Scala does support nulls. But perhaps Scala could have come up with a better solution that still allows null use when necessary. If you think of some syntax and elegant semantics for allowing you to forget about null for most code, I’d be interested to see your proposal.
        adamwbarr 12y ago
        I agree that the design is a result of trading off the desire to do away with nulls vs retaining Java interoperability. Preventing (at compile time) only Options from being null is surely impossible when casting/reflection are available. It is commonly understood that if an API returns Option[A] then the client can assume it will not return null. Personally I have never experienced a real error from this.
        the_af 12y ago
        Oh, I understand why null was needed (backwards compatibility, like you said), and I'm no language designer, so I don't know what I would have done instead. Maybe mark pieces of code that must interact with Java code with "unsafe" blocks, outside of which no nulls can escape? unsafe { ... } Don't know if this would work. I'm just disappointed because this slightly breaks the Option type, that's all.
the_af 12y ago
I don't understand your objection: // The type of 'unsafe' is Option[String] var unsafe = Option("some string") unsafe = null unsafe map println gives Exception in thread "main" scala.MatchError: null effectively a NullPointerException. This would be impossible for a true Option (aka Maybe) type. The problem is introduced because Scala, for backwards compatibility reasons, still allows the assignment of null; this lowers the usefulness of pattern matching against Option types. -- edit: you could object to my use of var (and you should). Ok, let's re-write it to be a val: def unsafeFunction(x: Option[String]): Option[String] = { x orElse null } ... val unsafe = unsafeFunction(None) unsafe map println ...and I still get the NPE. Note that in this case you can easily see how I introduced the problem, but the point is that the signature for unsafeFunction should guarantee null is not a possible return value.
- virtualwhys 12y ago
  // The type of 'unsafe' is Option[String] var unsafe = Option("some string") unsafe = null unsafe map println Is complete contrived nonsense, var? Seriously, quit trolling, in Scala (immutable) val is king. Next: def unsafeFunction(x: Option[String]): Option[String] = { x orElse null } Oh yeah, that's brilliant, let's just try our hardest to come up with scenarios that never occur in the "real" world (unless we try really hard to create nullthing out of nonething).
  - the_af 12y ago
    I'm not trolling. I genuinely want to like Scala, which is why I'm disappointed by some of its design choices. Yes, in Scala val should be king (unfortunately, it's not -- if you've taken the two Coursera courses by Odersky you'll see some use of var in the exercises, refuting your claim). But it's true val is more common, and the use of var was accidental to my point anyway (mutation wasn't the issue), hence my clarification and second example. Yes, it's pretty obvious where I introduced the mistake, I said as much. In the real world, the mistake might be harder to spot, which is why the type system shouldn't allow it. If I understand your position correctly, it seems to boil down to "programmers will code correctly, therefore this static check (that Option must not be null) isn't needed". Which is pretty much what dynamic typing proponents have been saying all along. A pretty untenable position if you want to stay on the side of Scala... I'd much prefer if Option were more like Haskell's Mabye, but then again, I side with static typing. I understand why, given Scala's requirements, this wasn't possible. It's just disappointing.

> Indeed, Option in Scala has the same problem eh? scala> val safe = Option(null) safe: Option[Null] = None

adamwbarr 12y ago

scala> val x = Some(null) x: Some[Null] = Some(null)

virtualwhys 12y ago
That's pretty contrived, when would you _ever_ wrap a thing that could be null in a Some? Even so, to continue with your example: scala> x foreach println null x.get res2: Null = null Hey, what do you know, no NPE. Try harder ;-)
- adamwbarr 12y ago
  Ok fair point re it being contrived! Although (having just re-read it), the original post's complaint was actually that: > the compiler (afaik) doesn't prevent you from setting an Optional field to null ie scala> val option: Option[Any] = null option: Option[Any] = null
  - the_af 12y ago
    Exactly, that was my complaint. It makes elegant pattern matching against Option types (the whole point of using them, in fact) less than useful. Now, in Scala-land, you have to check that they aren't null, which sucks.
    - frowaway001 12y ago
      This complaint shows pretty well that some people have never actually used Scala.
      - the_af 12y ago
        Can you elaborate? The whole point of Option types is that I can map (for example) over them without explicitly checking what their value is, and it will work without a runtime error. Same with pattern matching. With the introduction of null, this is no longer possible. I've just shown an example of getting an NPE while mapping over an Option[String]. Now we're back in Java-land, where I must explicitly check for nulls, read the source code of every method or trust some comment that tells me that it will never return null. (Ok, not exactly like Java-land: a Scala programmer who returns a null for a function with type Option is very inexperienced or is doing something naughty. But why does the language even allow it?) Aside from telling me I'm wrong, can you explain why?
        roryokane 12y ago
        Scala needed to support null somehow in order to interoperate with arbitrary Java code, such as passing null as a parameter to a third-party Java library. So at least some variables should be allowed to have null. Maybe they couldn’t think of a way to prevent Option-typed variables from being null without preventing arbitrary Java interop. Making only Option types reject nulls might have been thought too hacky. Those are just my guesses of the design rationale, working from the fact that Scala does support nulls. But perhaps Scala could have come up with a better solution that still allows null use when necessary. If you think of some syntax and elegant semantics for allowing you to forget about null for most code, I’d be interested to see your proposal.
        adamwbarr 12y ago
        I agree that the design is a result of trading off the desire to do away with nulls vs retaining Java interoperability. Preventing (at compile time) only Options from being null is surely impossible when casting/reflection are available. It is commonly understood that if an API returns Option[A] then the client can assume it will not return null. Personally I have never experienced a real error from this.
        the_af 12y ago
        Oh, I understand why null was needed (backwards compatibility, like you said), and I'm no language designer, so I don't know what I would have done instead. Maybe mark pieces of code that must interact with Java code with "unsafe" blocks, outside of which no nulls can escape? unsafe { ... } Don't know if this would work. I'm just disappointed because this slightly breaks the Option type, that's all.

the_af 12y ago

I don't understand your objection: // The type of 'unsafe' is Option[String] var unsafe = Option("some string") unsafe = null unsafe map println gives Exception in thread "main" scala.MatchError: null effectively a NullPointerException. This would be impossible for a true Option (aka Maybe) type. The problem is introduced because Scala, for backwards compatibility reasons, still allows the assignment of null; this lowers the usefulness of pattern matching against Option types. -- edit: you could object to my use of var (and you should). Ok, let's re-write it to be a val: def unsafeFunction(x: Option[String]): Option[String] = { x orElse null } ... val unsafe = unsafeFunction(None) unsafe map println ...and I still get the NPE. Note that in this case you can easily see how I introduced the problem, but the point is that the signature for unsafeFunction should guarantee null is not a possible return value.

virtualwhys 12y ago
// The type of 'unsafe' is Option[String] var unsafe = Option("some string") unsafe = null unsafe map println Is complete contrived nonsense, var? Seriously, quit trolling, in Scala (immutable) val is king. Next: def unsafeFunction(x: Option[String]): Option[String] = { x orElse null } Oh yeah, that's brilliant, let's just try our hardest to come up with scenarios that never occur in the "real" world (unless we try really hard to create nullthing out of nonething).
- the_af 12y ago
  I'm not trolling. I genuinely want to like Scala, which is why I'm disappointed by some of its design choices. Yes, in Scala val should be king (unfortunately, it's not -- if you've taken the two Coursera courses by Odersky you'll see some use of var in the exercises, refuting your claim). But it's true val is more common, and the use of var was accidental to my point anyway (mutation wasn't the issue), hence my clarification and second example. Yes, it's pretty obvious where I introduced the mistake, I said as much. In the real world, the mistake might be harder to spot, which is why the type system shouldn't allow it. If I understand your position correctly, it seems to boil down to "programmers will code correctly, therefore this static check (that Option must not be null) isn't needed". Which is pretty much what dynamic typing proponents have been saying all along. A pretty untenable position if you want to stay on the side of Scala... I'd much prefer if Option were more like Haskell's Mabye, but then again, I side with static typing. I understand why, given Scala's requirements, this wasn't possible. It's just disappointing.