Popular @
Forum Controls
Spotlight Features
The Rich Engineering Heritage Behind Dependency Injection
Andrew McVeigh takes us on a tour of the rich heritage behind dependency injection, what it represents, and tells us why its here to stay.
NetBeans 6: Matisse Updates
NetBeans 6 delivers great updates to the Matisse GUI builder. Spend a few minutes with Roman Strobl and get an expert briefing on what's new and what has changed. (sponsored)
Introduction to Groovy Part 3
In this, the third and final installation of Andres' Introduction to Groovy series, you learn about how Groovy handles variable numbers of arguments, named parameters, currying, and more about Groovy operators. Including, some new operators.
Easier Custom Components with Swing Fuse
Swing Fuse (actually just Fuse), is a framework designed to make it easier to create your own custom desktop components. In this article, Daniel Spiewak shows you how to get started and provides sample source code you can download.
Benchmark Analysis: Guice vs Spring
Willam Louth shows how he uses JXInsight Probes to investigate probable performance issues with code bases that he is not familiar with. He also highlights possible pitfalls in creating a benchmark, as well as in the analysis of results.
Should we Disrespect Null?
URL: Pwning Nil in Ruby
At 4:51 AM on Sep 3, 2007, Daniel Spiewak wrote:
Fresh Jobs for Developers Post a job opportunity
Personally, I've always believed that null should be a signal value. It's purpose in existance is to fill in for the absense of other values, thus providing a totally unique value to test for. In all other cases, its use should be non-sensical. The "Pwning Nil in Ruby" post seems to suggest we should be doing things like mathematical compuations based on nil, or even string construction. In fact, in the proposed nil extensions, nil's value would vary based on context and requirements. With these proposals, no longer is nil just a signal value with no sane purpose beyond. Instead, it becomes a full-fledged constant in its own right, standing for not just the absense of value, but an actual non-value which can take on any required form.
Is this even a reasonable idea? Should null remain pure? Or should we, with the aid of modern, dynlang programming techniques, redefine null into a newer, more flexible constant?
18 replies so far (
Post your own)
Re: Should we Disrespect Null?
http://www.refactoring.com/catalog/introduceNullObject.htmlhttp://today.java.net/today/2004/12/10/refactor.pdf
Re: Should we Disrespect Null?
Java's null is a legacy left from C 0 pointer.SQL has the correct way this UNKNOWN value is handled...
So basically we have to redefine what is NULL in Java. It even may be an object..... But unknown has to be left unknown.
Not like that post suggests that nil == 0 is false BUT nil.to_i == 0 is true... Since when is unknown value equal to 0?
Re: Should we Disrespect Null?
I have mixed feelings about this. Surely it's much nicer, conceptually, to handle null values as either a neutral operand (e.g. "string" + null = "string" like in SQL, not "stringnull" like in Java), or an "absorbing" operand (again in SQL: x + null = null, and not NPE like in Java5 with autoboxing).The problems is that in languages with richer and extensible typesystems, including OOPLs like Java, you have to maintain this semantics for every new type. So, for every single method / function / operator in your whole language / APIs / application, you have to either (a) handle null values for all operands/parameters in some consistent neutral way, or (b) explicit forbid that value at compile- or run-time, e.g. with some "NonNull" static type declaration (coming up with JSR305). At least (a) is a huge load of work, that's why the current handling of null in most languages and programs is so popular.
Re: Should we Disrespect Null?
I personally like the way that Null is handled in OCaml. You don't have a null keyword you only have a 'Maybe' type which can either be a Null or a Just. Transcribed into Java would like some thing like.public interface Maybe {
T get();
boolean isNull();
}
public class Null implements Maybe {
public T get() {
throw new NullPointerException();
}
public boolean isNull() {
return true;
}
}
public class Just implements Maybe {
private final T value;
public Just(T value) {
this.value = value;
}
public T get() {
return value;
}
public boolean isNull() {
return false;
}
}
Using that approach you can only return a Null value if a method defined to return a Maybe. E.g.
public class Map {
public Maybe get(V key);
}
I'm not suggesting anyone use this pattern for their Java code, but it an interesting approach in that it is much clearer to someone using an API as to whether a value can be Null or not. It also makes the designer think clearly about which values can be Null.
Mike.
Re: Should we Disrespect Null?
Yes, this is also used in Haskell and I think other languages with a sophisticated typesystem (SML etc?) - I think that's the "bottom" type. (Which BTW also exists in Java, but in current Java it is hidden, exists solely in formal specs... in the closures proposal there's an idea of exposing this type with a new wrapper java.lang.Unreachable. That would represent (in reflection) the type of closures that never return normally, e.g. because they terminate with an unconditional exception.) Handling nulls at the typesystem level, not with explicit runtime checks, is very elegant and powerful.But in Java (or other languages with a more traditional, static OO typesystem) I don't think it's possible to emulate (or even retrofit) this stuff. An application-level implementation like your Maybe class would perhaps fit in some very rewarding, low hanging fruit use cases; elsewhere it's too much work and overhead, and "just" a tiny part of the benefit you have in languages designed to work like that.
Re: Should we Disrespect Null?
Leave my null alone!Re: Should we Disrespect Null?
"Java's null is a legacy left from C 0 pointer."No, it's not. Java-like null values go back to at least the 1960's, and they are certainly not obsolete (as your use of the term "legacy" suggests).
Re: Should we Disrespect Null?
Sounds like a clever hack and a great way to write code you'll spend hours trying to understand two weeks after you wrote it...NetBeans.org
Evangelist/Senior Staff Engineer, Sun Microsystems
Re: Should we Disrespect Null?
> Sounds like a clever hack and a great way to write> code you'll spend hours trying to understand two
> weeks after you wrote it...
Yeah, that's my main concern with this. Standards and theoretical best practices are in place for a reason: they actually *do* make life easier. Messing around with the definition of null seems like a really good way to complicate your life unnecessarily.
ActiveObjects: an Easier Java ORM; Fuse: Resource Injection for Java
Re: Should we Disrespect Null?
Ok...It was inherited from C...
Since C is probably the closest relative, having the same thing... And it is directly inherited from pointer to address 0, thus NullPointerException and not something like NullValueException or UnknownValueException....
Re: Should we Disrespect Null?
> Leave my null alone!Hahahaaa... Funnnyyyyyy!
Was this message generated like "Leave my "+thing+" alone!" because you forgot to set value for String thing field?
Re: Should we Disrespect Null?
The advantage of ruby is not that it eliminates null. It supports developers in doing better than just returning a null. Personally, i prefer to return a specific object instead of nulls. What java and more important: my ide lacks is better support for that. This could be done by standardizing and implementing three items:1. An annotation could be used to mark a function as 'NeverReturnsNull'. Ide and compiler should generate a warning for null-checks of the returned value and an error for returning a null.
2. An interface could be used to mark a return type as 'NeverReturnedAsNull'. Compiler and ide should implement identical checks as described for item 1. This interface would define just one method like 'isNullSurrogate()'.
3. (This is an option, but i miss that feature most) Mark a class as overriding all methods of its (immediate ?) parent. The compiler should generate default-implementations that return nulls. You would only need to override a method manually if its return type is covered by items 1 or 2.
In the absance of operator overloading, this will not go as smooth as in ruby. But i do not think that is necessary: IMHO, one identical Object replacing each and every null would just lead to confusion. It is incorrect to mix non existent state with a predefined state for a certain situation. The examples given demonstrate what i mean by confusion: If you use the null-replacement in an addition, it behaves as if it were a zero. Used in a multiplication, it behaves like a one. This is surely a way to confuse readers of your code.
I concur to the comments regarding SQL: if you truly want to use nulls in arithmetics, you have to go all the way. The result of a boolean operation could then be one of 'true', 'false' or 'unknown'. Adding a null would return 'unknown'. If i am not mistaken, this is not what we are talking about here. (And surely there is a library out there implementing this very same arithmetics.)
Re: Should we Disrespect Null?
I think having nil/null as a first class object makes lots of sense. Certainly in the database world its invaluable, and if anyone has ever written a relational mapper they'll know about the kludges that are present to make some types "invalid" when a null is returned.Where I would have an argument with the way it is handled in Ruby is perhaps the way the operators are defined:
e.g. in the article a = true, b = nil, c = a | b = true - feels like an incorrect way to handle it. I think that null should generally be reductive i.e. a | b = nil - because the nature of "nil" is that it is an undefined value.
Perhaps the only place where it is valid to be non-reductive is in the case of string concatenation where string + nil = string.
nil of course should be typed - and if you perform an operation such as nilstring.length() should of course be nil.
Re: Should we Disrespect Null?
And it is directly inherited from pointer to address 0No. Even in C, the null pointer is not defined to be a pointer to address 0.
Since C is probably the closest relative, having the same thing...
Despite superficial syntactic similarities, C is not the closest relative to Java.
Java is a safe, statically typed, object-oriented language, and arguments about what to do with null in Java should be based on experience with such languages, not with C.
AFAIK, all such languages have null pointers or the equivalent thereof. There are some statically typed non-OO languages that have eliminated null, but they have more sophisticated type systems than Java.