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

151–160 of 164 posts

Re: What if null was an Object in Java?

#151

Post by nyssos »

zigzag312 wrote: post #135
dwaite wrote: post #111

Earlier quoted context omitted.

The biggest impact is on generic code - you don't want supplying Foo? as T rather than Foo to mean that there are side effects where successful returns and error cases are both represented by null.

In some cases (limited) nesting really seems useful. Nullable parameters for a Copywith method is another one (does null value mean 'no change' or 'set it to null'). The thing is that nullable covers majority of cases and is quicker to read and write (Foo? vs Option ). Doing a?.b?.c is also more elegant than anything equivalent using an Option type. Is there any languages that successfully combines both, nullable '?'…

The Haskell equivalent `c b a` is roughly as concise.

Re: What if null was an Object in Java?

#152

Post by tubthumper8 »

evrimoztamur wrote: post #66
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…

That sounds like you should be using Result to handle the two E cases you are describing. Success with Ok(T), with Err(Missing File) plus Err(Missing Setting).

Which you can't do in C# either without sum types :)

Re: What if null was an Object in Java?

#153

Post by tubthumper8 »

goatlover wrote: post #115
mbb70 wrote: post #10

Ruby has a `NilClass` and the best/worst part of it is the to_s is "", to_i is 0, to_f is 0.0, to_a is [], to_h is {} It's incredibly clean and convenient until you wake up one morning and have no idea what is happening in your code

Those conversions make sense though. They all mean empty or null. It's what I would expect from a language like Ruby.

Integer 0 means empty with respect to a particular operation (addition) but is not empty with respect to all operations (ex. multiplication)

Re: What if null was an Object in Java?

#154

Post by kbolino »

charleslmunger wrote: post #78
hedora wrote: post #25

Earlier quoted context omitted.

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 fi…

This too is thanks to JSR-133. In fact, it seems that, thanks to this part of JSR-133, what I said above about marking shared volatile is actually unnecessary. There must be a memory barrier somewhere, under the hood, though.

Re: What if null was an Object in Java?

#155

Post by Kamq »

codebje wrote: post #95
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's the other way around: null needs to be a subtype of MyType, not a supertype: anywhere I can pass a MyType I should be able to pass a null. You could get most of the way to the blog post's outcomes by simply adding a few methods to Object (is(Not)Null, primarily) and having null be a magic (because it's all classes and none) instance that will NPE on all but the few defined Object methods, I think, but none of th…

Correct. In type theory, a type that is a subtype of all other types is called a bottom type: https://en.wikipedia.org/wiki/Bottom_type

Re: What if null was an Object in Java?

#156

Post by charleslmunger »

kbolino wrote: post #154
charleslmunger wrote: post #78

Earlier quoted context omitted.

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 fi…

This too is thanks to JSR-133. In fact, it seems that, thanks to this part of JSR-133, what I said above about marking shared volatile is actually unnecessary. There must be a memory barrier somewhere, under the hood, though.

At least on android arm64, looks like a `dmb ishst` is emitted after the constructor, which allows future loads to not need an explicit barrier. Removing `final` from the field causes that barrier to not be emitted.

https://godbolt.org/#g:!((g:!((g:!((h:codeEditor,i:(filename...

Re: What if null was an Object in Java?

#157

Post by DaiPlusPlus »

chopin wrote: post #150
DaiPlusPlus wrote: post #49

Earlier quoted context omitted.

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.

But an int can't be null. If a method takes or returns an int it's guaranteed to be not null.

…yes; that’s my point.

Re: What if null was an Object in Java?

#158

Post by fud101 »

tialaramex wrote: post #140
nextaccountic wrote: post #100

Earlier quoted context omitted.

Seeing all this discussion reinforces the idea that no new programming language should have this "every type implicitly contains null" thing

Tony Hoare calls it (null) his Billion Dollar Mistake. https://www.infoq.com/presentations/Null-References-The-Bill...

We use None in Python - is that similar?

Re: What if null was an Object in Java?

#159

Post by nextaccountic »

fud101 wrote: post #158
tialaramex wrote: post #140

Earlier quoted context omitted.

Tony Hoare calls it (null) his Billion Dollar Mistake. https://www.infoq.com/presentations/Null-References-The-Bill...

We use None in Python - is that similar?

Yes, and no dynamically typed language can do much better than this, because in those your value of type X can always be another type (and you need to defensively check if you want to catch errors)

Re: What if null was an Object in Java?

#160

Post by jjav »

hn_throwaway_99 wrote: post #84

The problem isn't really that null isn't an object, it's that the type system allows any object reference of a particular class to also be null. After using Typescript for the past couple years, it's such a joy when you define a variable of type Foo and know it won't contain null. Granted, TS also has to deal with undefined vs null weirdness (and even more weirdness in that an object not containing a property is subt…

> it's such a joy when you define a variable of type Foo and know it won't contain null

Why is that? I've never seen a good explanation of this point of view.

This all feels like just syntactic sugar to me. Sure you might not have null, you might have an empty object or any other variation. At the end of the day, if a value was expected to be available but is not available (for whatever reason), reliable code is going to have to deal with that absence. No matter how it is expressed.

Post reply on HN