41–50 of 164 posts
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 love using Ruby when I'm the only one who will ever have to look at or touch it.
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?
YMMV. Obviously it depends on your teammates.
Earlier quoted context omitted.
The Nullable class is nice and I love to use it but it would be even better with an option type like in F#
There isn’t any big difference between T? And Option semantically. Many code bases use an Option in C# to indicate a 0-or-1 object result, but refactor those to T? instead with nullable. It combines better e.g Option > doesn’t need to be handled manually.
So T? doesn't compose, while Option does, which I'd consider a big difference.
However, without a builtin option type, duck-typing, or a pleasant way of converting the types, Option may become a hassle (especially when different dependencies ship their own). And as T? is shipped with the language this is probably why it is used when the composability is not required.
P.S.: In C# T? even neatly composes.
return obj?.a?.b
if (obj != null && obj.a != null) {
return obj.a.b
} else return null;I don't actually think it solves any problems. You still have to null check.
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.
For example, this is code that any C or C++ compiler will happily run and do something:
struct Bar {
int b;
};
struct Foo {
struct Bar bar;
} foo;
strcpy((char*)(&foo), "ABC");
int& foo(int* p) {
return *p;
}
int &r = foo(nullptr); //UB, but in practice will likely result in a null reference at runtime
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
Integer, + => 0
Float, + => 0.0
Array, add => []
Hash, merge => {}
and so on.
I think maybe we can debate the operations/functions, but they make sense. For Integer in some ways you can define almost all other operations that you commonly use based on the addition.
So while nil is an object when trying to find a representation in other group I find it logical or expected.
Also Ruby will not automatically try to coerce nil when not asked to do so
like for example 0 + nil will throw an error.
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.
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?