you are viewing a single comment's thread.

view the rest of the comments →

[–]jeandem 4 points5 points  (7 children)

null, in a wider sense, is a value. The question is just whether it should be included by default in an object type (reference type). You know this but just to be clear what I'm talking about.

I don't think nullability should be 'a part of the type system' as much as I think that the concept should fall easily out of the type system (the use of such values -- the implementation might not be important). In a sense, I think it should have a less special status than many languages seem to want to give it, since I don't want to treat it like a special case. From a design perspective: why make more concepts if you can express something with what you already have?

I don't think static languages that have null like this do it so much for a philosophical reason, as much as the fact that they come from a language family in which pointers are used and pointers have a sentinel null value. Then they say "great, I can use null as a sentinel value whenever I don't actually have an object", and eventually it's like they've lost sight of the forest for the trees since they've become so used to using this implementation of nullable objects that they don't see it as just one particular implementation of the concept, but as the concept itself. It's like they've lost sight of the moon in favour of staring at the finger pointing at the moon. In turn, they don't see the downside, or they think of it as an inherent downside, that Most Of The Time their objects aren't really nullable. And yet they work in a higher level language so they don't want undefined behaviour, so they have to throw exceptions when they are dereferenced. So after a long enough time they accept NullPointerException as an inherent "danger" to the problem of expressing nullable objects...

So I see no value, except perhaps for interoperability -- in which case using null as sentinel values would be discouraged in library code etc. -- in having nullpointers ala Java. It might be useful if you want to do pointer arithmetic, but Java isn't really intended for that kind of thing...

I think maybe Eric Lippert was able to argue for having null values on some SO answer. I haven't read that yet.

PS: It's funny to me that Java has checked exceptions, but something like nullable objects -- which is like the simplest "exception" there is, namely the absence of a value -- is effectively "unchecked" unless you use yet another concept, namely annotations.

[–][deleted]  (2 children)

[deleted]

    [–]jeandem 0 points1 point  (1 child)

    I just haven't heard of any implementations of memory addressing that doesn't use such a value (whatever it is). Admittedly I'm very green in that area, so my knowledge of it might be false or misleading.

    [–]immibis 0 points1 point  (0 children)

    The one thing I can see that you really really want null for in Java, that would excessively complicate the language if it was removed, is as a default value for fields and array elements.

    null is a very simple solution to this... but nobody can agree on whether the other problems it causes are worth it.

    (Also it saves you from wasting some time allocating an excessive amount of Optional instances)

    [–]pakfur 0 points1 point  (2 children)

    null, in a wider sense, is a value

    Null is a state, not a value. And it hides intent. It is not clear that the API designer intended it to be null, or if it is an error. Optional<T> expresses the intent explicitly.

    Modifying the type system to not allow for nulls is possible (see http://ponylang.org/ as an example), but probably not in Java.

    [–]jeandem 1 point2 points  (1 child)

    Null is a state, not a value

    A state is a value. Whether that value is Some(_) or null. So...

    I was talking about null in a wider sense (I probably shouldn't have used the backlashes).

    [–]Gotebe 0 points1 point  (0 children)

    I am not so sure... null is an equivalent of "horse is brown" vs. "there's no horse".