Hacker News Reader

Comment by jeroenhd | Hacker News Reader

Why don't the nullability examples use Java's Optional?

This code:

  if (nullableVariable != null) {
      boolean success = nullableVariable.someMethodCall()
      if (success) {
          return success
      } else {
          return fallbackIfNullMethodCall()
      }
  } else {
      return fallbackIfNullMethodCall()
  }

Could also be written something like this:

  result = Optional.ofNullable(nullableVariable)
                   .map(NullableType::someMethodCall)
                   .orElse(fallbackIfNullMethodCall());

Sure, it's no Elvis operator, but it's a lot more readable than the "standard" if/else structure of traditional Java. If we're comparing Java and Kotlin, we should at least give Java a fair chance. I dislike the verbosity of the Optional wrapper, but it's a lot better than if/else checking.

View on HN

Even the simple if/else approach can be done more cleanly (i.e. without repeating the fallback call):

  boolean success = false;
  if (nullableVariable != null) {
      success = nullableVariable.someMethodCall();
  }
  if (success) {
      return success;
  } else {
      return fallbackIfNullMethodCall();
  }

Even that seems way too much. The original would be much easier as:

  if (nullableVariable != null) {
      boolean success = nullableVariable.someMethodCall()
      if (success) {
          return success;
      }
  }
  return fallbackIfNullMethodCall();

And even that can be more concise if you prefer:

  if (nullableVariable != null && nullableVariable.someMethodCall()) {
      return true;
  }
  return fallbackIfNullMethodCall();

That's 9 lines of code vs. 3, and one additional variable. Cognitive load from lots of verbosity like this adds up.

How does the order of evaluation work in the second form there? Will fallbackIfNullMethodCall() be evaluated even if not returned?

It can be done this way:

  result = Optional.ofNullable(nullableVariable)
                   .map(NullableType::someMethodCall)
                   .orElseGet(() -> fallbackIfNullMethodCall());

This was what I intended to write. Sorry, the HN input box isn't my usual IDE :)

Makes sense, thanks.

or even:

  result = Optional.ofNullable(nullableVariable)
                 .map(NullableType::someMethodCall)
                 .orElseGet(this::fallbackIfNullMethodCall);

My code contains a bug, the code driver733 wrote is what I intended to write (usually I use predefined variables for orElse, conditionally taking the method call threw me of guard).

Java's Optionals can be `Some | None | null` right? They're just reference types still.

the intension is that the Optional reference is not null (despite it being _possible_ due to how references work in java). And it's fairly easy to add annotations like @NotNullable or some other compile time annotation which can be checked very easily by an IDE or other tool.

There's a very special level of hell for people who use both Optional.empty() and (Optional<?>) null for different things.

Just to play the devils' advocate, what happens if you want to represent the absence of having a value? that is, the Optional is not None (because it hasn't been computed yet).

Special. Hell.

(Actually that sounds like a Future<Optional<T>> or something.)

If you create a null reference to an Optional in any code base I have to deal with I will hunt you down and hurt you.

No jury of peers would convict.

Here's an even shorter one-liner:

return nullableVariable != null && nullableVariable.someMethodCall() ? true : fallbackIfNullMethodCall();

"? true :" is equivalent to just "||".

And "X && Y || Z" is usually equivalent to "X ? Y : Z".

So "nullableVariable != null ? nullableVariable.someMethodCall() : fallbackIfNullMethodCall();".

If X is true and Y is false this returns Y instead of Z which is wrong.

This works in this case, but the pattern is less easy when the result is not a boolean.

But I agree, in this specific case using a ternary operator after a null check is probably easier.

That's shorter, but I find the given example more legible.

I completely agree. I'll make that change soon.

Thanks for the feedback.

Is the actual logic different in Java vs Kotlin examples?

In Java: when `nullableVariable` is not null and someMethodCall() return `false` then we return what `fallbackIfNullMethodCall()` returns right? and in Kotlin in that case we just return `false` from `someMethodCall()` because this is not null and `fallbackIfNullMethodCall()` is not even evaluated?

Reply on news.ycombinator.com