6 ms·

Exactly. The problem is not that there is a null, it is that it is a valid value for all types (e.g. you can pass null to a function that expects a String). Al

• kqr 10y ago
  Isn't it, in practise, basically the same thing though? The theoretical difference is this: 1. Option is a regular data type/object that represents "a collection of at most one value". It's similar to a list, set, heap, tree or whatever other collection types you have, except it can not contain more than one value. 2. With explicit nulls I guess any data type (e.g. Integer) will automatically get a clone of itself (a different type named Integer?) where also null is a valid member. From a purely theoretical standpoint, I like #1 better.
  • greydius 10y ago
    In practice, it's not the same thing. Here's a Java example where I want the type system to enforce that a method in `ClassB` can only be called from `ClassA`. However, the fact that `null` circumvents the type system makes this pattern just wishful thinking. class ClassA { private static final Witness witness = new Witness(); final static class Witness { private Witness() {} } void callClassBMethod(ClassB classB) { classB.onlyClassACanCallThisMethod(witness); } } class ClassB { void onlyClassACanCallThisMethod(ClassA.Witness witness) { // ... } }
  • kmiroslav 10y ago
    The downside of `Option` is that it's a wrapper, and as such, you need to `flatMap` (or similar) whenever you want to access the wrapped value. By encoding `null` in its type system, Kotlin lets you manipulate these values directly which leads to code that is much less noisy and just as safe.
    • airless_bar 10y ago
      Not really. The main strength of the first approach is that Option is only one type out of many error-handling structures. Not every error is handled appropriately by Option/?. If you have a language like Kotlin where they hard-coded one way of handling errors, it feels very unidiomatic to pick a better fitting error handling type, while in languages where errors are handled by library code, it's a very natural approach.
      • kmiroslav 10y ago
        > Not every error is handled appropriately by Option/?. Which is expected since these two constructs are not aimed at handling errors: they manage missing values. > If you have a language like Kotlin where they hard-coded one way of handling errors No, no. `?` is not for handling errors. Kotlin is as agnostic as Scala for managing errors: you are free to use exceptions, dumb return values or smarter ones (`Either`, `\/`, `Try`, ...).
        • airless_bar 10y ago
          Yeah, it's just that-if you look at every language ever designed-if the language ships with a built-in construct developers will use and abuse it on every occasion, and every other approach lingers in obscurity. > Which is expected since these two constructs are not aimed at handling errors: they manage missing values. Which is a very small part of handling errors in general. As Kotlin offers special syntax for only this case, developers tend to shoehorn many errors into the "missing-value" design to get the "nice" syntax even if a different approach would have been more appropriate. > Kotlin is as agnostic as Scala for managing errors: you are free to use exceptions, dumb return values or smarter ones (`Either`, `\/`, `Try`, ...). That's not true in practice: Just have a look at funktionale: Despite providing almost the same as Scala's error handling types (partially due to the blatant copyright violations) almost nobody uses it. This is a direct result from having a "first-class" construct in the language: It turns library-based designs into second-class citizens. That's the thing Scala got right, and many of the copy-cat languages got wrong.
  • SatvikBeri 10y ago
    I think Option[String] and "String?" are semantically both a union type–they both effectively add one possible value to the underlying type, along with a constructor for naturally extending functions on that type–Kotlin's "?" operator is equivalent to Scala's map or Haskell's fmap, etc.
    • airless_bar 10y ago
      Option[Option[String]] != String??
      • junke 10y ago
        Option[Option[String]]? Is this a Church Numeral?
      • SatvikBeri 10y ago
        My impression, though I'm not sure, is that Kotlin simply won't allow you to do a double "??". Scala etc. will technically allow Option[Option[Something]], but in practice you would almost never want to use it, and can easily avoid it with flatMap.
        • airless_bar 10y ago
          The whole point of this was to show that Scala's types preserve the structure of the computation. It might not be very interesting in the Option[Option[String]] case but imagine Try[Either[String, Int]] or List[Future[Double]]. It's a very important distinction. Collapsing cases is one of the primary thing why exceptions sometimes get a bad rap, and Kotlin (and Ceylon) do the same with ? (and |, &) at the value level.