31–40 of 164 posts
value = get(collection, key) do
error(“$key in the collection not found”)
This syntax has captivated my attention lately as it seems like a viable alternative to doing an explicit null check before using the value.
Earlier quoted context omitted.
Wait, javas Optional is a reference type so it can be null? Doesn’t that almost defeat the purpose of it?
Yup. Your IDE will likely highlight it as an issue, but it's totally legal to return a null Optional. There's nothing special about it, it's just a wrapper class.
Earlier quoted context omitted.
null can be avoided with a good linter
Not avoided altogether. Static checkers cannot possibly follow all code paths, and they generally err on the side of false negatives rather than risking too many false positives causing people to disable them.
Earlier quoted context omitted.
Yup. Your IDE will likely highlight it as an issue, but it's totally legal to return a null Optional. There's nothing special about it, it's just a wrapper class.
Did the project to add value types to Java (I’m sure I heard of it a decade ago) never finish?
Earlier quoted context omitted.
An Optional is just a tri-valued null (null, None, and Some), so no. It'd be nice if Java had a concept of a never-null reference (like a C++ reference vs. a C++ pointer), but the @NotNull annotation wasn't enforced the last time I checked. Also, there's no way for an object to express that invariant because encapsulation is so weak. Given only this constructor (and no reflection): Foo() { foo.bar = new Bar(); /* foo…
Wait, javas Optional is a reference type so it can be null? Doesn’t that almost defeat the purpose of it?
Basically Java had nulls from the start. A decade or so later some people who didn't like nulls introduced their own Optional type, as a third-party library. Enough people liked it that Optional was added to Java's standard library.
But as it's just an object, it can be null. Some null avoidance enthusiasts also use third-party @Nullable and @NotNull annotations, which some automated code checking tools will attempt to verify during compile/test.
Earlier quoted context omitted.
An Optional is just a tri-valued null (null, None, and Some), so no. It'd be nice if Java had a concept of a never-null reference (like a C++ reference vs. a C++ pointer), but the @NotNull annotation wasn't enforced the last time I checked. Also, there's no way for an object to express that invariant because encapsulation is so weak. Given only this constructor (and no reflection): Foo() { foo.bar = new Bar(); /* foo…
Wait, javas Optional is a reference type so it can be null? Doesn’t that almost defeat the purpose of it?
Every non-primitive is nullable in Java. Adding Optional doesn't/can't change that.
You can have a gentlemen's agreement to prefer None to null.
Earlier quoted context omitted.
Assuming that was the only constructor you defined on class Foo, and you used this.bar instead of foo.bar (latter won't compile), then the caller can't possibly get a Foo with bar set to null (except by reflection, and there are ways to prevent that). Moreover, even if new Bar() did throw an (unchecked) exception, the invariant would still hold, since Foo would rethrow the exception. This has always been the case, as…
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.
Earlier quoted context omitted.
Not avoided altogether. Static checkers cannot possibly follow all code paths, and they generally err on the side of false negatives rather than risking too many false positives causing people to disable them.
I wasn’t aware they preferred type II errors. That makes sense, but I don’t really expect tools like that to work across modules.
I don't actually think it solves any problems. You still have to null check.
null would just mean the zero value instead of the absence of a value String foo = null; String bar = ""; foo.equals(bar) --> true This works well provided the data type has a sensible zero value like collection types EDIT: I'm blocked from posting so I won't be responding further, thank you for discussion.
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?
Ruby has a `NilClass` and the best/worst part of it is the to_s is "", to_i is 0, to_f is 0.0, to_a is [], to_h is {} It's incredibly clean and convenient until you wake up one morning and have no idea what is happening in your code
I somehow can't help reading that as some sort of high school sports-cheer: "Gimme an S to the quote to the I to the oh to the F to the zero! Goooo Rubies!"