On Sunday, 19 May 2013 at 18:22:16 UTC, deadalnix wrote:
On Sunday, 19 May 2013 at 18:05:03 UTC, Idan Arye wrote:
These are the assumptions I'm working with:
- We can't use a nullable reference
- We can't initialize the reference upon declaration to it's
real value.
If you can't initialize the value, you got to assume when you
use it that it may not have been initialized and handle that
case. You need either an Option (where you have to be explicit
about what you do when the thing is null) or a Maybe (where
null is ignored and Maybe "contaminate" every result depending
on a maybe value).
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 - so now it will be
perceived as `None`, and you will have the same problem.
The first assumption is required because we want to describe
how the bug scenario deadalnix brought up would look like if
references were non-nullable. The second assumption is
required because if we could initialize the reference upon
declaration to it's real value, we should have just done it in
the first place and avoid the whole race hazard.
But that is the whole point ! The damn thing should have been
initialized in the first place to avoid the bug. And this
should have been caught at compile time with any sane type
system.
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...
Now, I'm not saying the solution I presented is good - I'm
trying to show that given those two assumptions, we are forced
to use this bad solution.
This solution is complex, do not make any sense in a strongly
typed language and don't even solve the presented case.
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.
