RE: Nonnullability

by Naftoli Gugenheim :: Rate this Message:

Hi. I certainly understand how NotNull is much more convenent than annotating potentially every definition! However, as I pointed out in my message, it does not seem to suffice to prevent nulls in the many places that use non-user types. In a simple lift program that for the most part one file with two related models and one snippet source file (so far ;)), amost the entire snippet file is flooded with warnings about nullability! Pretty soon you just filter out the warnings mentally.
myEntity.name has to be a String, not a Nullable[String]. If any function f possibly returns a value that's defined in a library (e.g. a function call), there's no way to use properies of the return value of f without getting warnings. So I can't keep track of where null is indeed a danger.
My suggestion was for now, to allow for a definition or type annotation to be annotated as a guarantee to the compiler that it will never equal null. When the type inherits NotNull, the compiler should add this annotation automatically. Eventually, NotNull could be seen as one possible proof of nonnullability, and other proofs could be added. For example:
def getAll = em.createNamedQuery[Author]("findAllAuthors", "id"->id).getResultList match {
case null => Nil
case seq => seq
}
But the various proofs don't need to be added right now. Right now only one small change would make a big difference: allow definitions (or type annotations) to be annotated with a user guarantee that it won't be null, and suppress nullability warnings in such cases. And it could be simplified into one rule, by generating such annotations for types inheriting NotNull.

-----Original Message-----
From: Ricky Clarkson <ricky.clarkson@...>
Sent: Thursday, June 04, 2009 4:21 AM
To: Naftoli Gugenheim <naftoligug@...>
Cc: scala-debate@...
Subject: Re: [scala-debate] Nonnullability

The reason is that we only want to do it once per type, not on every
single declaration. If it bothers you, write a Nullable[T] that
behaves like Option[T], but defines n=null to be like n=None, and
gives toString appropriately. Don't try to get equals/hashCode
semantics right transparently, you won't.

2009/6/3 Naftoli Gugenheim <naftoligug@...>:

> 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

« Return to Thread: Nonnullability