On Sun, 19 May 2013 21:02:11 +0200, Idan Arye <[email protected]> wrote:
I don't see how Option and Maybe would have helped your bug. The problem
was that somewhere in the code the reference was perceived as null while
in fact it wasn't
What does that even mean?
- so now it will be perceived as `None`, and you will have the same
problem.
Except that now the code would be forced to handle the None case. In a way,
having nullable by default is like having a stringly typed system:
function foo( s ) {
return (s + 4) * 2; // Works great when s == "16", falls dead on its
// back when s == "goobers".
}
function bar( int i ) {
return (i + 4) * 2;
}
These functions look very different. That's because they are. One of them
only takes valid parameters, the other takes any old garbage and barfs
when the wrong garbage is given to it.
Of course, if you have a string, and you want to call bar, you need to
convert the string to an int. So you end up with this:
function baz( string s ) {
return s.parseInt(
i => bar(i),
{ alert("error"); });
}
Notice how the parseInt function takes two delegates? One of these
(the first) is only called when the string is valid. The other is only
called if the string is invalid. That way, we can be sure that the
failure case is handled.
Exactly the same would be the case for non-nullable pointers - if you
want to convert a nullable pointer to non-nullable, you *have* to
handle the failure case. No two ways about it.
Now, the same example with class references:
int foo(A a) {
return a.qux(); // Works great when a == new A(), falls dead on its
// back when a == null.
}
int bar(NonNull!A a) {
return a.qux();
}
See how one of these does not blow up in your face (unless you do
something stupid like create a special Nil value that will do exactly
that)? Now, for baz:
int baz(A a) {
return a.match(
(NonNull!A a) => bar(a),
(None) => -1
);
}
And this is the exact problem with nullable by default : plenty of
stuff ends up be null is some weird situation that almost never occurs
when they are assumed not to be and the program crashes.
NullPointerException now return 4 millions result on google, which is
probably around once per java developers.
This is not a problem with "nullable by default" - it is a problem with
implicit default values. null(or Nil, or None) are the only sane default
values for reference types - I think you would agree that having to
construct a new blank object as default value for every reference
variable would be far worse than null...
If you absolutely cannot initialize the pointer to something sensible,
then use a nullable pointer. But if non-nullable pointers are not
available, or are harder to use than nullable pointer, then people will
use nullable pointers even where non-nullable would have been a much
more fitting choice.
It does not solve the bug - it is something you HAVE to do given the
assumptions. If the reference is not nullable, and you can't set it to
it's real value until later in the code, then you have to initialize it
to some temporary value.
I don't know enough about the bug to say such things for sure, but I will
say this: If deadalnix solved the bug, he is likely in a much better
position to say anything about what would solve the problem than the rest
of us.
--
Simen
