On Sunday, 19 May 2013 at 17:46:13 UTC, Simen Kjaeraas wrote:
On Sun, 19 May 2013 19:12:15 +0200, Idan Arye
<generic...@gmail.com> wrote:
It's a good practice to initialize references(and all other
types of variables) as soon as possible - and if possible,
right away in the declaration. If that reference started as
null, it's safe to assume it was not possible to initialized
it at declaration, so it was intentionally initialized with
null(if there was no initialization Java would scream at you).
Now, let's assume that reference was non-nullable. It is safe
to assume that this change would not remove the obstacle that
prevented that reference from being initialized right away in
the declaration - so you still need to initialize it to
something else - let's call that something `Nil`. Nil is an
object that tells you that the reference has not yet been
initialized.
Uhm, no. Nononono. No. This is a complete and utter fallacy.
What you
have just done is define Nullable!(NonNullable!T). I should not
have to
explain too closely why this is a bad thing and should not be
done.
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.
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.
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.
