3 ms·

> I think they're relatively simple to avoid? Most issues in software fall into this category, though. The issue with Java’s null is that it’s not type safe. T

> I think they're relatively simple to avoid? Most issues in software fall into this category, though. The issue with Java’s null is that it’s not type safe. The language is generally a strongly typed language, except in the case of null. And until Value Types land, there is no way to express nullability to the compiler. The arguments you make aren’t all that different than the undefined behavior arguments with C. “Just follow these simple rules and you’ll avoid all issues”, a compiler should do that for you IMO. I can’t wait for Value Types in Java, at that point we can have real Option types.

chucksmash 8y ago
Right. No downvote, but GP post conflates "how code SHOULD be written" with "how existing code was written" in my opinion. Same with one of the earlier comments about "idiomatic C++ does bounds checking." I've seen plenty of NPEs in real, working Java. If Mozilla isn't managing to write idiomatic C++, I don't hold out much hope for myself either. > “Just follow these simple rules and you’ll avoid all issues”, a compiler should do that for you IMO. This was one thing I really liked about Kotlin vs Java. It's nice that my IDE can do the work of generating getters/setters on a POJO for me, but it's not nice that the language requires me to fill my source code with that noise. To a first approximation, any task rote enough the computer could do it for me, it should not ask me to do. See also: static languages that don't offer type inference.
andrekandre 8y ago
this is just an honest question, and i’m genuinely curious, but why couldn’t Optional<T> be done as an immutable reference type... why does it need value types to be implemented first?
- bluejekyll 8y ago
  do you mean like a final field in an class?
  - andrekandre 8y ago
    i was thinking something like that, yes
    - bluejekyll 8y ago
      It’s still not a “guarantee” that it’s not null, but you can be somewhat more confident that it isn’t if you assign it in all constructors of the type. For params and return values you still can’t know for sure, and in all these cases it -could- be null. But yes, making all fields and variables that are Optional would help as a coding practice, except of course where you need to reassign the value in the Optional, as there is no “set” on the type.

chucksmash 8y ago

Right. No downvote, but GP post conflates "how code SHOULD be written" with "how existing code was written" in my opinion. Same with one of the earlier comments about "idiomatic C++ does bounds checking." I've seen plenty of NPEs in real, working Java. If Mozilla isn't managing to write idiomatic C++, I don't hold out much hope for myself either. > “Just follow these simple rules and you’ll avoid all issues”, a compiler should do that for you IMO. This was one thing I really liked about Kotlin vs Java. It's nice that my IDE can do the work of generating getters/setters on a POJO for me, but it's not nice that the language requires me to fill my source code with that noise. To a first approximation, any task rote enough the computer could do it for me, it should not ask me to do. See also: static languages that don't offer type inference.

andrekandre 8y ago

this is just an honest question, and i’m genuinely curious, but why couldn’t Optional<T> be done as an immutable reference type... why does it need value types to be implemented first?

bluejekyll 8y ago
do you mean like a final field in an class?
- andrekandre 8y ago
  i was thinking something like that, yes
  - bluejekyll 8y ago
    It’s still not a “guarantee” that it’s not null, but you can be somewhat more confident that it isn’t if you assign it in all constructors of the type. For params and return values you still can’t know for sure, and in all these cases it -could- be null. But yes, making all fields and variables that are Optional would help as a coding practice, except of course where you need to reassign the value in the Optional, as there is no “set” on the type.