RE: Nonnullability

> I am trying to understand the position of defining nonnullability as a
> property of a type rather that of a val/var/def.
> For instance, I am writing a (so far very simple) app in Lift. There are
> tons of warnings everywhere an external method is called that returns a type
> that doesn't extend NotNull. I have an entity, called Nature. I made it
> extend NotNull. Now everywhere that had a valid possibility of a null Nature
> has to be changed to store an Option. Not the end of the world, although
> whether to use None or null to indicate emptiness should be the decision of
> the storage site, not the class -- why should such a decision be all or
> nothing? If the language would not have a concept of null it would be one
> thing. Okay. Now I want my helper lookup to return Seq[Nature] with NotNull.
> Now if nullability were a property of the site, you could check if the API
> lookup returns null and return Nil etc. instead. But being that Seq (or any
> type in a parallel situation) wasn't defined by me and the return value
> isn't instantiated by me, (and even if it was it wouldn't help for a final
> type) I can't ensure to return a subtype of NotNull. You can't just cast to
> NotNull. So for Seq you can use a SeqProxy as a hacky workaround.
> Another use case is nonnullable Strings (that have to be java.lang.Strings
> for one reason or another, e.g. AppEngine JPA entities). (Anyway, for e.g