Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

What if null was an Object in Java?

donraab.medium.com

Post reply on HN
Print view View original

71–80 of 164 posts

Re: What if null was an Object in Java?

#71

Post by klysm »

DSMan195276 wrote: post #68
m_fayer wrote: post #7

I think the nullable reference type system in c# is a perfectly workable compromise for languages that had nullability from the very beginning. Once a code base uses them fully, most null-related bugs are gone. And it’s far from an unwieldy bolt-on.

It's funny because I really dislike the C# approach. It's not truly enforced - any code with nullable disabled can call public functions with `null`, even if on your side they were marked as non-null.

Yup, unfortunately for us there is a lot of C# code written without NRT. If all of your code utilizes NRT and you respect the warnings, you can nearly eliminate issues related to null. There are some paper cuts around generics, but generally it has been working quite well for me. Our entire code base has NRT enabled and the only place where null sneaks in is with EF Core missing includes. This is actually kinda nice because if you get a null-whatever exception, 99% of the time it's a missing include.

Re: What if null was an Object in Java?

#72

Post by klysm »

aloisdg wrote: post #11
m_fayer wrote: post #7

I think the nullable reference type system in c# is a perfectly workable compromise for languages that had nullability from the very beginning. Once a code base uses them fully, most null-related bugs are gone. And it’s far from an unwieldy bolt-on.

The Nullable class is nice and I love to use it but it would be even better with an option type like in F#

One important distinction I didn't get at first is that Nullable is a struct (not a class). It is only for value types. Nullable reference types are implemented via attributes.

Re: What if null was an Object in Java?

#73

Post by DonHopkins »

Would a prototype based system like Self or JavaScript allow you to attach custom properties and methods to individual instances of Null? That would be so cool!

Nihilistic Oriented Programming is where you don't use any classes, just customized instances of null.

Re: What if null was an Object in Java?

#74

Post by int_19h »

specialist wrote: post #62

What if every null reference was an instance of a Null Object pattern? https://en.wikipedia.org/wiki/Null_object_pattern Eliminates null checks, Optionals, and NPEs. Probably moots annotations like @NotNull too, but maybe some use cases need those for client APIs. Makes iterating data structures like graphs simple. Faster too, because the JIT NOP a Null Object's methods. (Mostly; profile to confirm, then tweak as nee…

Not everything has a sensible null object.

It also means that forgetting to set a value will often silently give wrong results instead of immediately producing an error.

Re: What if null was an Object in Java?

#75

Post by ipv6ipv4 »

krackers wrote: post #48

Objective-c allows you to send messages to null objects. On one hand it allows for a form of null-coalescing, but on the other it allows bugs to slip in and get the program into an unexpected state, whereas a more rigorous treatment would result in a more deterministic crash.

It is part of what makes Objective-C phenomenally good for rapid development in the hands of competent developers. However, as team, and codebase sizes increase, it allows for subtle bugs by less competent developers.

Re: What if null was an Object in Java?

#76

Post by Kamq »

DaiPlusPlus wrote: post #49
Kamq wrote: post #6

Earlier quoted context omitted.

There's no reason that something can't both an object and the bottom of the type hierarchy. It's, technically, an instance of multiple inheritance. Java doesn't generally allow this, but there's tons of special cases in the compiler for things that you can't do yourself. For example, defining operators is done in the compiler, but you can't define operators for your own classes.

It would be a bottom-type of reference-types. This wouldn’t work for value-types like int, at least not without boxing, which would be very painful.

Fair, but those are kind of off in their own in the java hierarchy as is.

Re: What if null was an Object in Java?

#77

Post by exabrial »

I like the way null is handled in Java, I think it’s pretty well thought out, other than the small awkwardness with basic types.

Contrast that with SQL, which had my external scorn for null != null

So you can do WHERE table.col = Null…. Ugh

Re: What if null was an Object in Java?

#78

Post by charleslmunger »

hedora wrote: post #25
kbolino wrote: post #17

Earlier quoted context omitted.

Assuming that was the only constructor you defined on class Foo, and you used this.bar instead of foo.bar (latter won't compile), then the caller can't possibly get a Foo with bar set to null (except by reflection, and there are ways to prevent that). Moreover, even if new Bar() did throw an (unchecked) exception, the invariant would still hold, since Foo would rethrow the exception. This has always been the case, as…

Doing it requires two threads. Thread A sets a shared reference to a newly allocated and null initialized reference to Foo: shared = new Foo(); While that's running, thread B invokes a method on the reference that assumes bar is non-null: shared.useBar(); // null pointer exception Later, thread A runs the constructor for Foo.

That's not accurate for a final field, as final fields are initialized in a special way.

https://docs.oracle.com/javase/specs/jls/se21/html/jls-17.ht...

>An object is considered to be completely initialized when its constructor finishes. A thread that can only see a reference to an object after that object has been completely initialized is guaranteed to see the correctly initialized values for that object's final fields.

If you don't publish a reference to the object from within the constructor, you will not see a null value of the final field, even if the object itself was unsafely published across threads via a non-volatile field.

Re: What if null was an Object in Java?

#79

Post by Twisol »

zigzag312 wrote: post #64
ablob wrote: post #44

Earlier quoted context omitted.

I'm going to be a bit pedantic here: There is a semantic difference between Option > and Option . If I intend to retrieve a setting from a file, the former allows me to differentiate between a missing file or a missing setting, while the latter destroys that information. i.e.: There are 3 possible cases, while only 2 can be represented. So T? doesn't compose, while Option does, which I'd consider a big difference. Ho…

> There is a semantic difference between Option > and Option . If I intend to retrieve a setting from a file, the former allows me to differentiate between a missing file or a missing setting Does nesting Option's really has practical use or does it quickly become confusing? In your example, Option > return type doesn't tell me by itself that this differentiates between a missing file or a missing setting. I would ne…

Sometimes you'll have nested Options just because you're mapping a fallible operation over a fallible input. You don't want the resulting `Option>` to immediately collapse; then you wouldn't know which upstream operation failed. It's true that `Option>` is very generic (i.e. it doesn't inherently tell you what each None means), but flattening Options removes more information; it isn't a solution to the problem you're posing. At least you can post-process an `Option>` into a multi-variant, self-documenting result type before you pass the value off to some other consumer.

In other words, nested optionals might not be very readable, but they're a necessary product of having a highly modular, reusable toolkit, and you can always massage them into more informative, domain-specific types at whatever point that becomes appropriate.

Re: What if null was an Object in Java?

#80

Post by lisper »

Another option in the language design space which this article doesn't mention is to have different kinds of null indicating what kind of object this null value is intended to be a stand-in for. NULL is a generic non-value, but it's also possible to have null-number, null-string, null-character, etc. which can be handy for detecting certain kinds of type errors. In particular, a constructor for a class C can return a null-C if it fails, which can be very useful for debugging. One of the problems with generic NULLs is that it can be very hard to track down where they came from.
Post reply on HN