61–70 of 164 posts
Earlier quoted context omitted.
Right that depends if you subscribe to the belief that null means the absence of a value `Option ` or does it mean the zero value `T`.
Null is the absence of a value. How do to distinguish 0 from no value?
Eliminates null checks, Optionals, and NPEs. Probably moots annotations like @NotNull too, but maybe some use cases need those for client APIs.
Makes iterating data structures like graphs simple. Faster too, because the JIT NOP a Null Object's methods. (Mostly; profile to confirm, then tweak as needed.)
I implement a Null Object for each base class.
Each base class has a static final member NULL referencing its Null Object implementation (flyweight, singleton). Then assign variables to AwesomeThing.NULL instead of null.
A spiffy javac could code generate Null Object implementations. (It's on my todo list.) For scalars, just use the default null value should be. int is 0, float is NaN, etc. Their boxed values will need small shims too.
Customizing javac (with some compiler plugin or something) is deep down on my TODO list. So I'm unlikely to be the (first) person to do this work. Sorry.
Earlier quoted context omitted.
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.
I'm going to be a bit pedantic here: There is a semantic difference between Option > and Option . If I intend to retrieve a setting from a file, the former allows me to differentiate between a missing file or a missing setting, while the latter destroys that information. i.e.: There are 3 possible cases, while only 2 can be represented. So T? doesn't compose, while Option does, which I'd consider a big difference. Ho…
Does nesting Option's really has practical use or does it quickly become confusing?
In your example, Option> return type doesn't tell me by itself that this differentiates between a missing file or a missing setting. I would need to get this information from somewhere else.
Earlier quoted context omitted.
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.
I'm going to be a bit pedantic here: There is a semantic difference between Option > and Option . If I intend to retrieve a setting from a file, the former allows me to differentiate between a missing file or a missing setting, while the latter destroys that information. i.e.: There are 3 possible cases, while only 2 can be represented. So T? doesn't compose, while Option does, which I'd consider a big difference. Ho…
Earlier quoted context omitted.
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.
I'm going to be a bit pedantic here: There is a semantic difference between Option > and Option . If I intend to retrieve a setting from a file, the former allows me to differentiate between a missing file or a missing setting, while the latter destroys that information. i.e.: There are 3 possible cases, while only 2 can be represented. So T? doesn't compose, while Option does, which I'd consider a big difference. Ho…
Rust has dozens of helper methods for option - like map, map_or, map_or_else, and so on. When you’re starting out, it’s quite hard to find what you want in the morass of options. And many of the helper functions take a closure, which messes up your ability to do control flow (return, break, continue) from the containing function. In Swift, like typescript, I found the syntax sugar around options to be much easier to learn. Eg obj?.a?.b rather than checks docs obj.and_then(|o| o.a).and_then(|a| a.b).
“If let” in rust helps. (Similar to guard let in Swift) Ie, you can write if let Some(x) = x { … }. But you still can’t combine that with other conditions in the if statement - which drives me nuts.
I think the nullable reference type system in c# is a perfectly workable compromise for languages that had nullability from the very beginning. Once a code base uses them fully, most null-related bugs are gone. And it’s far from an unwieldy bolt-on.
I think the nullable reference type system in c# is a perfectly workable compromise for languages that had nullability from the very beginning. Once a code base uses them fully, most null-related bugs are gone. And it’s far from an unwieldy bolt-on.
Of course the Rumsfeld Matrix further breaks down the three different types of unknowns.
https://en.wikipedia.org/wiki/There_are_unknown_unknowns
>"Reports that say that something hasn't happened are always interesting to me, because as we know, there are known knowns; there are things we know we know. We also know there are known unknowns; that is to say we know there are some things we do not know. But there are also unknown unknowns—the ones we don't know we don't know. And if one looks throughout the history of our country and other free countries, it is the latter category that tends to be the difficult ones." -Donald Rumsfeld
1) Known knowns: These are the things we know that we know. They represent the clear, confirmed knowledge that can be easily communicated and utilized in decision-making.
2) Known unknowns: These are the things we know we do not know. This category acknowledges the presence of uncertainties or gaps in our knowledge that are recognized and can be specifically identified.
3) Unknown unknowns: These are the things we do not know we do not know. This category represents unforeseen challenges and surprises, indicating a deeper level of ignorance where we are unaware of our lack of knowledge.
And Microsoft COM hinges on the IUnknown interface.
https://en.wikipedia.org/wiki/Tony_Hoare#Research_and_career
>Speaking at a software conference in 2009, Tony Hoare apologized for inventing the null reference:
>"I call it my billion-dollar mistake. It was the invention of the null reference in 1965. At that time, I was designing the first comprehensive type system for references in an object oriented language (ALGOL W). My goal was to ensure that all use of references should be absolutely safe, with checking performed automatically by the compiler. But I couldn't resist the temptation to put in a null reference, simply because it was so easy to implement. This has led to innumerable errors, vulnerabilities, and system crashes, which have probably caused a billion dollars of pain and damage in the last forty years." -Tony Hoare
https://news.ycombinator.com/item?id=19568378
>"My favorite is always the Billion-Dollar Mistake of having null in the language. And since JavaScript has both null and undefined, it's the Two-Billion-Dollar Mistake." -Anders Hejlsberg
>"It is by far the most problematic part of language design. And it's a single value that -- ha ha ha ha -- that if only that wasn't there, imagine all the problems we wouldn't have, right? If type systems were designed that way. And some type systems are, and some type systems are getting there, but boy, trying to retrofit that on top of a type system that has null in the first place is quite an undertaking." -Anders Hejlsberg