Null references redux

[Denis Koroskin]

On Sun, 27 Sep 2009 02:49:06 +0400, Walter Bright  
<newshound1 at digitalmars.com> wrote:

> Denis Koroskin wrote:
>> On Sun, 27 Sep 2009 01:49:45 +0400, Walter Bright  
>> <newshound1 at digitalmars.com> wrote:
>>
>>> The problem with non-nullable references is what do they default to?  
>>> Some "nan" object? When you use a "nan" object, what should it do?  
>>> Throw an exception?
>>>
>>  Oh, my! You don't even know what a non-null default is!
>>  There is a Null Object pattern  
>> (http://en.wikipedia.org/wiki/Null_Object_pattern) - I guess that's  
>> what you are talking about, when you mean "nan object" - but it has  
>> little to do with non-null references.
>
> It's the black hole object. It prevents you from getting a seg fault,  
> but I see no rationale for expecting that an unexpected null object  
> always returning "I succeeded" means your program will operate correctly.
>
> The white hole object, of course, always throws an exception when it is  
> accessed. At least you know something went wrong - but you already have  
> that with null.
>
>
>> With non-null references, you don't have "wrong values", that throw an  
>> exception upon use (although it's clearly possible), you get a correct  
>> value.
>
> You're not getting a correct value, you're getting another default value.


I'm sorry but I can not continue discussion with you like that. You are  
not listening! You are not even trying to understand what I say. We are  
talking *completely* different things here.

Who the hell cares if it's a black or white as long as it is a hole  
object? I tell you that no one is gonna use it, because it's *much* easier  
to do everything right (i.e. initialize a reference to proper value) than  
create Hole classes for each of the class/interface. I can't even imagine  
anyone writing the code like this:

T someFunction(Args someArgs) {
     ISomeInterface someInterface = new  
BlackHoleOfSomeInterfaceThatAlwaysThrows(); // let's initialize that  
variable to some dumb value just to make compiler happy
     // rest of the method body
}

Novices, maybe. But professionals would never do that sin for sure.

*Please* let's go past that pattern, it really has nothing to do with  
proposed non-null by default references.

> If the logic of your program is expecting a prime number > 8, and the  
> null object returns 0, now what?
>

You are talking heresy here. I'm afraid you don't even know what you are  
talking about.

A) There is no such thing as null object. That's bullsh*t! No one ever  
proposed to use those, you did. And now you deny use of them and discuss  
how bad they are.
B) You can't call a function that accepts non-null T if you don't have a  
valid (i.e. non-null) T reference. End of story.

>> If an object may or may not have a valid value, you mark it as  
>> nullable. All the difference is that it's a non-default behavior,  
>> that's it. And a user is now warned, that an object may be not  
>> initialized.
>
> He isn't warned, that's just the problem. The null object happily says  
> "I succeeded" for all input and returns more default values and null  
> objects.
>

Please stop that "null object" pattern propaganda. Did you even read what  
I wrote?

I wrote: if a variable may be not initialized - no problem, make it  
nullable and assign a null! A user is now forced to check that variable  
against a null before dereference and must take appropriate actions if it  
is null.

> What happens if the output of your program then becomes a null object?  
> How are you going to go about tracing that back to its source? That's a  
> lot harder than working backwards from where a null exception originated.
>
> I used to work at Boeing designing critical flight systems. Absolutely  
> the WRONG failure mode is to pretend nothing went wrong and happily  
> return default values and show lovely green lights on the instrument  
> panel. The right thing is to immediately inform the pilot that something  
> went wrong and INSTANTLY SHUT THE BAD SYSTEM DOWN before it does  
> something really, really bad, because now it is in an unknown state. The  
> pilot then follows the procedure he's trained to, such as engage the  
> backup.
>
> A null pointer exception fits right in with that philosophy.
>
> You could think of null exceptions like pain - sure it's unpleasant, but  
> people who feel no pain constantly injure themselves and don't live very  
> long. When I went to the dentist as a kid for the first time, he shot my  
> cheek full of novacaine. After the dental work, I went back to school. I  
> found to my amusement that if I chewed on my cheek, it didn't hurt.
>
> Boy was I sorry about that later <g>.

That's trolling, Walter. I'm sorry, but you are talking non-sense here.
Once again, no one ever proposed use of null object pattern. You imagined  
it and now denying its use.