5 ms·

I suppose that means that it is 'null' which is evil in Java. If you're going to get rid of pointers, and you still want to have the option of a thing existing

by mjevans 10y ago

I suppose that means that it is 'null' which is evil in Java. If you're going to get rid of pointers, and you still want to have the option of a thing existing or not, you therefore must represent it with a list and a contract on the size of the list. (Zero entities, or one entity in the case of a 'single object reference.) Otherwise you'd only be able to detect 'missing' objects by exceptions being thrown.

theemathas 10y ago
I recommend that you read section 6.2 (The Billion-Dollar Mistake) in the linked paper. Most important part of that section: > If our community wants to remove implicit nulls from industry, where appropriate, our community should make greater effort to appreciate the complex compromises that have to be made in practice so that our work can successful transfer out of academia.
danking00 10y ago
What you've described is precisely the Optional or Maybe type. Many folks worry about the efficiency, which is reasonable, but feels misguided. A nullable annotation would be sufficient for the safety we all crave and would have no runtime overhead (i.e. It would still represent missingness with null.)
- lmm 10y ago
  The problem is that then your Optional is a special kind of type that only works on reference types, and you either can't instantiate Optional<int> or it has radically different performance characteristics from most Optionals.
johan_larson 10y ago
I can live with the notion of nulls. But I think having all (non-primitive) function parameters be nullable is a huge mistake. It is just very rarely what the writer actually wants. And explicitly checking for null for all object parameters is a huge pain. The right solution, to my mind, would be to have function parameters be non-nullable by default. Unfortunately it is too late in the history of Java to switch to that behavior now. Too much code would break. So I would settle for being able to declare individual function parameters non-nullable as a standard part of the language. I can't believe it would be all that hard to implement.

by mjevans 10y ago

theemathas 10y ago

I recommend that you read section 6.2 (The Billion-Dollar Mistake) in the linked paper. Most important part of that section: > If our community wants to remove implicit nulls from industry, where appropriate, our community should make greater effort to appreciate the complex compromises that have to be made in practice so that our work can successful transfer out of academia.

danking00 10y ago

What you've described is precisely the Optional or Maybe type. Many folks worry about the efficiency, which is reasonable, but feels misguided. A nullable annotation would be sufficient for the safety we all crave and would have no runtime overhead (i.e. It would still represent missingness with null.)

lmm 10y ago
The problem is that then your Optional is a special kind of type that only works on reference types, and you either can't instantiate Optional<int> or it has radically different performance characteristics from most Optionals.

johan_larson 10y ago

I can live with the notion of nulls. But I think having all (non-primitive) function parameters be nullable is a huge mistake. It is just very rarely what the writer actually wants. And explicitly checking for null for all object parameters is a huge pain. The right solution, to my mind, would be to have function parameters be non-nullable by default. Unfortunately it is too late in the history of Java to switch to that behavior now. Too much code would break. So I would settle for being able to declare individual function parameters non-nullable as a standard part of the language. I can't believe it would be all that hard to implement.