Timeline for Are null references really a bad thing?
Current License: CC BY-SA 3.0
25 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Jun 2, 2016 at 2:14 | comment | added | Paul Carroll | Couldn't agree more with your arguments @JensG, this all seems like syntactic sugar for toast as opposed to cooked bread. Another article pointed me to en.wikipedia.org/wiki/… though, where I can see more use when doing pure functional programming. | |
| Apr 10, 2015 at 22:34 | comment | added | Jules |
@JensG Making up a C#-like syntax for Maybes, something like Maybe<Drink> drink = IsSunday() ? Maybe.Just(GiveMeADrink()) : Maybe.None(); would be about right.
|
|
| Mar 14, 2014 at 14:46 | comment | added | JensG |
Maybe<Drink> drink; if( IsSunday()) drink = GiveMeADrink(); - damn, doesn't compile. How can I solve this?
|
|
| Mar 14, 2014 at 13:13 | comment | added | Doval |
@JensG You're missing the point. A variable of type Foo should only contain Foos. The language shouldn't be allowing you to write uninitialized variables in the first place. From a computational perspective, it makes no sense.
|
|
| Mar 14, 2014 at 9:17 | comment | added | JensG | What does you null object return when asked for a value? | |
| Mar 14, 2014 at 5:45 | comment | added | sea-rob | Agree that null object is better. Ultimately, though, pointers/references need to go into a context that separates an "actual" pointer/reference from nullity. That involves "lifting" the pointer into a context that differentiates known valid, or known no. An old-school approach would be to carry two variables, pointer and pointer-is-set. But emerging techniques (and language mechanisms) formalize that context as a Type of its own. The benefit is that the compiler can work with that "lifted" type and provide nice compile-time guarantees. | |
| Mar 14, 2014 at 0:42 | history | edited | JensG | CC BY-SA 3.0 |
added 75 characters in body
|
| Mar 14, 2014 at 0:36 | history | edited | JensG | CC BY-SA 3.0 |
added 1851 characters in body
|
| Mar 13, 2014 at 21:06 | comment | added | JensG |
While I agree with the wrapping, I still don't see the difference of a pointer/reference pointing to an "invalid valid proxy" object and pointing to, well, just plain nothing - which techically is an address area that is protected by the OS against read/write accesses (at least with WinNT), so in fact even null is pointing to something - the invalid valid Nothing, the untouchable taboo memory.
|
|
| Mar 13, 2014 at 21:04 | comment | added | Tim Goodman |
@JensG in your latest example, does the compiler make you do the null check before every call to t.Something()? Or does it have some way of knowing you already did the check, and not making you do it again? What if you did the check before you passed t in to this method? With the Option type, the compiler knows whether you've done the check yet or not by looking at the type of t. If it's an Option, you haven't checked it, whereas if it's the unwrapped value then you have.
|
|
| Mar 13, 2014 at 21:02 | comment | added | Tim Goodman |
The compiler can force you to unwrap the maybe in the same way it prevents you from assigning an expression of compile-time type String to a variable of compile-time type Int. Whereas, with the null value, the compiler has to know the value of the expression to know you did something illegal, not just the compile-time type of the expression.
|
|
| Mar 13, 2014 at 21:00 | comment | added | JensG |
Won't compile any longer. I can't call t.Something() anymore, because now t is a maybe. The compiler forces to me unwrap it and check it is not null ... ah, sorry, no - null is not allowed anymore for some obscure reason. Of course I have to check against not being a Nothing.
|
|
| Mar 13, 2014 at 20:31 | comment | added | sea-rob |
Well, the "same check against null is 'technically' impossible" may be impossible at compile time. If I have a variable Thing t, make some function calls, then reference t.doSomething(), the compiler can't know whether t is valid. So t might have lost its type in execution, and become a sort of untyped reference (i.e. to null).
|
|
| Mar 13, 2014 at 20:29 | comment | added | JensG |
So the compiler can force me to unwrap the maybe and check whether it is Nothing. But enforcing the same check against null is "technically" impossible, because it ruins existing code. Is that what you are saying?
|
|
| Mar 13, 2014 at 20:24 | comment | added | Tim Goodman |
With the Option type, a "String that could be null" is a different type than a String, so the compiler can recognize when you're using a "String that could be null" as if it's a String without first doing the null check and extracting the String. If all strings can be null, then there's no reliable way for the compiler to tell. Heck, maybe the value of the String is coming from a closed-source third-party library... What's the compiler to do, read the documentation?
|
|
| Mar 13, 2014 at 20:18 | comment | added | Doval |
@JensG The compiler can't force you to check against null because any variable could be null. Keeping track of whether a varible is null or not would require executing the program. The other alternative is to throw a compile time error any time it can't figure out whether something contains null or not, which would obviously rule out tons of perfectly valid programs.
|
|
| Mar 13, 2014 at 20:15 | comment | added | Doval |
@JensG You can't forget to check it. A Maybe Gun is not a Gun. You can't call Gun methods on it, or pass it to methods expecting a Gun. Attempting to do so will result in a compile time error, no different from trying to call List methods on a Gun. You have to unwrap it and determine whether it contains Nothing or a Gun.
|
|
| Mar 13, 2014 at 20:14 | comment | added | JensG | Why can't the compiler force me the same way to check against null? | |
| Mar 13, 2014 at 20:13 | comment | added | Tim Goodman | @JensG The point is, you're forced to check it by the compiler. | |
| Mar 13, 2014 at 20:08 | comment | added | JensG |
Ok, you say I'm forced to check it, but even if you bring guns, I still might forget to check. What happens in that case (except pulling the trigger)? And how different is an InvalidTypeException compared to a NPE to the typical user? And why is a Nothing proxy instance simulating a "valid invalid object" better than a real nothing?
|
|
| Mar 13, 2014 at 20:05 | comment | added | Doval |
Well, you don't set them to any value, because you shouldn't allow them at all. Instead, you use a variable of a different type, perhaps called Maybe T which may contain either Nothing, or a T value. The key thing here is that you're forced to check if a Maybe really does contain a T before you're allowed to use it, and provide a course of action in case it doesn't. And because you've disallowed invalid pointers, now you never have to check anything that's not a Maybe.
|
|
| Mar 13, 2014 at 19:59 | comment | added | JensG | To what value would you set an invalid pointer? | |
| Mar 13, 2014 at 19:52 | comment | added | Doval |
Can you present an argument for why null should exist? It's possible to handwave just about any language flaw with "it's not a problem, just don't make a mistake".
|
|
| S Mar 13, 2014 at 19:48 | history | answered | JensG | CC BY-SA 3.0 | |
| S Mar 13, 2014 at 19:48 | history | made wiki | Post Made Community Wiki by JensG |