91–100 of 164 posts
Earlier quoted context omitted.
This is how I would do it. Go: *string Java: Option or @Nullable String Rust: Option TypeScript: string | undefined (or string | null)
The problem is, not all of these languages think that "" and null are equal.
I'd like a null on the same order as NaN. You can use it, compute new values with it, call methods on it, but all results are a similar NaV (not-a-value?).
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.
By that standard, C and C++ are much worse, since they offer no runtime encapsulation at all, and have much worse and more subtle multithreaded errors (e.g. Java at least guarantees that all native word sized reads/writes are atomic, if I recall correctly). C++ doesn't even guarantee that a reference can't be null, or worse, deallocated before it is dereferenced. They allow you to specify that a field is of some type…
If Null is not a subtype of MyType, then you wouldn't be able to assign null to a variable decalred as MyType, without breaking the rest of the rules of Java. I don't really see how this could work, even theoretically.
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.
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 that answers the burning question of _why_ that I feel the article doesn't really address.
I did hack MACLISP to have multiple NILs once. A surprising number of things appeared to run OK for a while. Of course the PDP-10 had a hardware addressing mode just for NIL so if you weren't the official one compiled code didn't believe you were a legit NIL.
Making another T was more boring, except that the few bugs that were triggered seemed to appear more quickly than in the NIL case. I guess a lot more people explicitly compared with 'T. Eh, grad students, what do you expect?
As to why I did this, well it was decades ago but surely a case of work avoidance.
I like the way null is handled in Java, I think it’s pretty well thought out, other than the small awkwardness with basic types. Contrast that with SQL, which had my external scorn for null != null So you can do WHERE table.col = Null…. Ugh
It's all inherited from C. Null works the same, references are just pointers, and primitives have to be boxed since collections store references. Not sure if I'd say it's well thought out, but coming from C, all the weirdness makes sense.
Earlier quoted context omitted.
By that standard, C and C++ are much worse, since they offer no runtime encapsulation at all, and have much worse and more subtle multithreaded errors (e.g. Java at least guarantees that all native word sized reads/writes are atomic, if I recall correctly). C++ doesn't even guarantee that a reference can't be null, or worse, deallocated before it is dereferenced. They allow you to specify that a field is of some type…
We can quibble on definitions here, but a reference in C++ can not be null. The undefined behavior happens before any assignment to a reference is executed so that at the moment that the assignment happens, the reference is guaranteed to not be null. In your example, it's the dereference of the pointer to p that is undefined behavior, so anything that happens after that point is also undefined behavior. Note that mea…
My point is that we can compare two things: valid programs, or programs that compile.
In valid C++ programs, references can't be null and there are no data races. In valid Java programs, all final fields initialized in an object's constructor have that value for the lifetime of the object.
If we compare invalid programs that compile, which is an important point as well, then those guarantees go out the window. But here Java is much more forgiving than C++: if you have improper synchronization, you may see fields which are null instead of having their final value, which is bad and confusing. But in C++ with improper synchronization, you can see literally any outcome at all.
Earlier quoted context omitted.
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 d…
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,…
> 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 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}).
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…