> We could discuss, of course, if Option[T] is really > such a clever solution to the nullability problem > in general.
Actually, from the perspective of a language designer, it is. You can eliminate the entire concepts of nulls from the language, and you don't need nullability annotations, it's all just application of the standard generics concept. It doesn't work that well in Java, but I guess Scala was built with better generics support. > To me, nullability isn't really a first-class citizen > in a type system. It should be secondary with respect > to T. With Option[T], code that can't be invaded by null Ts can simply use T and never worry about nulls, or even about whether there is such a thing as a nullability concept. With a hypothetical @Nullable T (or @Nonnull T), all code needs to know that nullability is an issue. You either sprinkle your code with null checks (for runtime checking) or with @Nonnull annotations (for compiletime checking). It's just useless boilerplate. Most of the time, you don't even WANT nulls. The thing is even more general. Things could be optional for more than one reason, for example, either because the proper value is either Unknown or it's Invalid to have such a value. With the Scala pattern, it's a simple variation, you just extend the pattern with Unknown in addition to None (which would be interpreted as Invalid). With nulls, now you need to add a flag to T. Multivalue nulls are also hairy from an application semantics perspective. There may be contexts in which Unknown does not make sense but Invalid does, and vice versa. Plus, you can't override code with Java nulls. We all have written our static isEqual(o1,o2) functions, until we found them in Apache Commons (or Hibernate or Guava or... or... or..., seems like every major project reinvented that particular wheel). With an Option type, that's easy. >From a slightly different perspective, Option is a trick to have a hook where >you can hang domain-specific null handling. Plus it's decoupled from the >semantics of T, so for those types T that can be coded without dealing with >nullability, null handling can be decoupled from T, which is generally a Good >Thing. > I wonder, how a library like jOOQ could reason > about a type like Option[T], once generics and the T > type have been erased from the information available > to the java.lang.reflect package. Not at all, but the flaw lies in Java's type erasure regime, not in the design of Option[T]. > But I guess that's another story. :-) Indeed :-) -- You received this message because you are subscribed to the Google Groups "jOOQ User Group" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/groups/opt_out.
