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

21–30 of 164 posts

Re: What if null was an Object in Java?

#21

Post by alkonaut »

jflwyasdf wrote: post #12
philipwhiuk wrote: post #4

I don't actually think it solves any problems. You still have to null check.

null would just mean the zero value instead of the absence of a value String foo = null; String bar = ""; foo.equals(bar) --> true This works well provided the data type has a sensible zero value like collection types EDIT: I'm blocked from posting so I won't be responding further, thank you for discussion.

A null collection and an empty collection are two different things. A nullable collection is one that has the state “no collection” semantically separate from “empty collection”.

Similarly an Option has 257 different values while a byte has 256 different values. That the byte has a good zero value doesn’t change that - the whole reason for choosing a maybe-byte is having 257 values, not 256.

Re: What if null was an Object in Java?

#22

Post by jflwyasdf »

golergka wrote: post #16
jflwyasdf wrote: post #12

Earlier quoted context omitted.

null would just mean the zero value instead of the absence of a value String foo = null; String bar = ""; foo.equals(bar) --> true This works well provided the data type has a sensible zero value like collection types EDIT: I'm blocked from posting so I won't be responding further, thank you for discussion.

In the end, you'll have a mixture of NULL and "" in your DB, and a couple of years later a piece of logic written in another language will fail spectacularly.

This is how I would do it.

  Go: *string

  Java: Option or @Nullable String

  Rust: Option

  TypeScript: string | undefined (or string | null)

Re: What if null was an Object in Java?

#23

Post by jflwyasdf »

alkonaut wrote: post #21
jflwyasdf wrote: post #12

Earlier quoted context omitted.

null would just mean the zero value instead of the absence of a value String foo = null; String bar = ""; foo.equals(bar) --> true This works well provided the data type has a sensible zero value like collection types EDIT: I'm blocked from posting so I won't be responding further, thank you for discussion.

A null collection and an empty collection are two different things. A nullable collection is one that has the state “no collection” semantically separate from “empty collection”. Similarly an Option has 257 different values while a byte has 256 different values. That the byte has a good zero value doesn’t change that - the whole reason for choosing a maybe-byte is having 257 values, not 256.

Right that depends if you subscribe to the belief that null means the absence of a value `Option` or does it mean the zero value `T`.

Re: What if null was an Object in Java?

#24

Post by alkonaut »

hedora wrote: post #8
randomopining wrote: post #3

Doesn't an Optional basically cover this case

An Optional is just a tri-valued null (null, None, and Some), so no. It'd be nice if Java had a concept of a never-null reference (like a C++ reference vs. a C++ pointer), but the @NotNull annotation wasn't enforced the last time I checked. Also, there's no way for an object to express that invariant because encapsulation is so weak. Given only this constructor (and no reflection): Foo() { foo.bar = new Bar(); /* foo…

Wait, javas Optional is a reference type so it can be null? Doesn’t that almost defeat the purpose of it?

Re: What if null was an Object in Java?

#25

Post by hedora »

kbolino wrote: post #17
hedora wrote: post #8

Earlier quoted context omitted.

An Optional is just a tri-valued null (null, None, and Some), so no. It'd be nice if Java had a concept of a never-null reference (like a C++ reference vs. a C++ pointer), but the @NotNull annotation wasn't enforced the last time I checked. Also, there's no way for an object to express that invariant because encapsulation is so weak. Given only this constructor (and no reflection): Foo() { foo.bar = new Bar(); /* foo…

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.

Re: What if null was an Object in Java?

#26

Post by Spivak »

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#

I think Option is an overrated construct when it's not a monad. The whole value is being able to write a chain of operations

    myobj.dothing(x).otherthing(y)
Without having to check the intermediate results. When it's just a tagged union you end up having to check for null everywhere anyway. It's better than "untyped" null because it can't pop up anywhere but it's not super ergonomic. I think Nullable where the Option is implicit does it better.

Re: What if null was an Object in Java?

#27

Post by simpsond »

hedora wrote: post #8
randomopining wrote: post #3

Doesn't an Optional basically cover this case

An Optional is just a tri-valued null (null, None, and Some), so no. It'd be nice if Java had a concept of a never-null reference (like a C++ reference vs. a C++ pointer), but the @NotNull annotation wasn't enforced the last time I checked. Also, there's no way for an object to express that invariant because encapsulation is so weak. Given only this constructor (and no reflection): Foo() { foo.bar = new Bar(); /* foo…

Yeah, I wish the VM would prevent null assignment of optional and force to empty. There are probably side effects I can’t think of here and certainly would cause problems with legacy code misusing optionals.

Re: What if null was an Object in Java?

#28

Post by golergka »

jflwyasdf wrote: post #22
golergka wrote: post #16

Earlier quoted context omitted.

In the end, you'll have a mixture of NULL and "" in your DB, and a couple of years later a piece of logic written in another language will fail spectacularly.

This is how I would do it. Go: *string Java: Option or @Nullable String Rust: Option TypeScript: string | undefined (or string | null)

The problem is, not all of these languages think that "" and null are equal.

Re: What if null was an Object in Java?

#29

Post by Defletter »

alkonaut wrote: post #24
hedora wrote: post #8

Earlier quoted context omitted.

An Optional is just a tri-valued null (null, None, and Some), so no. It'd be nice if Java had a concept of a never-null reference (like a C++ reference vs. a C++ pointer), but the @NotNull annotation wasn't enforced the last time I checked. Also, there's no way for an object to express that invariant because encapsulation is so weak. Given only this constructor (and no reflection): Foo() { foo.bar = new Bar(); /* foo…

Wait, javas Optional is a reference type so it can be null? Doesn’t that almost defeat the purpose of it?

Yup. Your IDE will likely highlight it as an issue, but it's totally legal to return a null Optional. There's nothing special about it, it's just a wrapper class.

Re: What if null was an Object in Java?

#30

Post by alkonaut »

jflwyasdf wrote: post #23
alkonaut wrote: post #21

Earlier quoted context omitted.

A null collection and an empty collection are two different things. A nullable collection is one that has the state “no collection” semantically separate from “empty collection”. Similarly an Option has 257 different values while a byte has 256 different values. That the byte has a good zero value doesn’t change that - the whole reason for choosing a maybe-byte is having 257 values, not 256.

Right that depends if you subscribe to the belief that null means the absence of a value `Option ` or does it mean the zero value `T`.

If null and [] should be the same thing then I’d make absolutely sure you can’t represent both. You don’t want two states representing the same thing. That should be easy to ensure if a language is reasonable. E.g a field that can’t be null (best case a non-nullable type, otherwise maybe a constructor guaranteeing it’s never null)

As the example of byte vs option either you want 256 states or you want 257. If you have 256 or 257 states you want to represent will decide which type is correct. The other choice of type is incorrect.

In some languages, these things are blurred because the language doesn’t let you choose a correct type for the state space, but I’m talking about the case where you can (coincidentally the set of languages I’d use).

Post reply on HN