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<byte> 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.
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<byte> 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).
The point is to eliminate the idea of an absence of a value. A variable is always assigned to a value, but there is a special value called null which behaves as a kind of sentinel value whose methods all return the null value for their respective type.
Yes - but as we keep repeating - if you do that why would you use null as a possible state to begin with? Not specific to Java, but in general.
E.g a boolean in java has two states true/false while a Boolean with capital B has 3 states true/false/null.
In that context you can choose type to represent how many states you have. E.g if it’s a field representing a cache of a bool value you can represent “not yet calculated” with null. It you were to magically convert null to false for a Boolean it only has two states! It’s now unusable for the purpose.
That just gets us back to the problem for which Null is introduced in almost every lamguage: indicating the absence of a value. This is an important feature in every language, and null is the most popular solution to it (the only significant alternative is the Maybe monad).
To put this in more concrete terms, if this change were integrated in Java, how would you indicate the difference between a JSON document which doesn't contain a field VS one where the field is an empty string?
I dare say there's a lot more use of a magic value to indicate no value than a distinguishable representation of it :-)
I base this mostly on an assumption of C still being one of the most widely used languages for the code that's running out there in the world. In C, after all, NULL is just a magic value rather than a distinguishable representation of no value, though that's just one example out of a host of others, all the way down to the venerable NUL-terminated string.
As for your question: something like 'keys(jsonobject).contains("fieldName")' ? Or 'NoSuchFieldException' thrown if you do 'jsonobject.get("fieldName")' ?
(The latter of which, given the general uneasiness NullPointerException creates in us devs, is often how a Java API will work anyway! Checked exceptions won the day! Until the Functional interface was made, at least.)
Or to answer it in the same spirit as this overall comment, why would you need to distinguish between missing and empty? Can't you just define the semantics of the document s.t. those two things having the same effect?
I don't agree that C's NULL is any different from Java's null or modern C++'s nullptr, at least outside of embedded contexts (where sometimes people actually store stuff at the 0 address). Sure, it's normallt just a macro that resolves to 0 at the implementation level. But people use it like in C++: you want to return an int, but also distinguish the case where no int could be returned? Return an int*, and NULL signifies no data.
> As for your question: something like 'keys(jsonobject).contains("fieldName")' ? Or 'NoSuchFieldException' thrown if you do 'jsonobject.get("fieldName")' ?
> (The latter of which, given the general uneasiness NullPointerException creates in us devs, is often how a Java API will work anyway! Checked exceptions won the day! Until the Functional interface was made, at least.)
I was thinking more of the case where you deserialize a JSON object into a Java object, and then inspect the Java object. Regardless, it was just an example - the problem of distinguishing "no value" from "any value" is pervasive in programming, and all languages must have some strategy for it. If we got rid of null from Java, then Option<T> would probably be the only general candidate. Which, to be fair, would be slightly better, as it would at least force you to check.
> Or to answer it in the same spirit as this overall comment, why would you need to distinguish between missing and empty? Can't you just define the semantics of the document s.t. those two things having the same effect?
Not in the general case, no. At least not without doubling every field and adding other inconsistency issues ({"result": "ABC", hasResult: false}).
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.
One response to this is issue is a CHECK constraint LENGTH(column) > 0, so you can’t have empty strings.
Rarely do you have a textual database column where the empty-vs-NULL distinction is semantically meaningful in the application domain. Most of the time, either the column value is missing (arguably better represented by NULL) or has a non-blank value. “Present but blank” is rarely meaningful or useful
Sometimes I pair that with (TRIM(column)=column) to prevent leading or trailing whitespace being saved, which also stops all-blank values being saved
This works really well if you have an RDBMS which supports CREATE DOMAIN, so then you can attach these constraints to a user-defined type and don’t have to repeat them for each column, you just set the type of the column to that user-defined type
I've been using sqlc, sqlx, pgtyped, & kysely and I found they have ORM-like productivity with full type-safety but they don't bring the baggage of leaky abstractions.
Unfortunately I don't know if there are Ruby or Python equivalents yet.
Since the "vet" maybe didnt give it away, 95% of the cncf landscape is a trashfire joke of hodge podgey vc funded golang crap.
This site is so damn funny. I reply to a burner account in a day old thread, and then my comment is downmodded less than 60 seconds later. Points to some shockingly pathetic behavior, dang maybe you could check the IP on that alt account, might be interesting.
EDIT: I'm blocked from posting so I won't be responding further, thank you for discussion.