Non-null objects, the Null Object pattern, and T.init

[H. S. Teoh]

On Fri, Jan 17, 2014 at 03:37:22PM -0800, Walter Bright wrote:
> On 1/17/2014 2:05 PM, H. S. Teoh wrote:
> >Of course, but that requires a few rounds of recompilation, repacking
> >the EEPROM image, installation on device, and repeating a user
> >interaction that possibly only randomly hits the bug. Hardly the work
> >of a few minutes.
> 
> I've done EEPROM programming & debugging, I know how to do it. Nulls
> still aren't a special kind of bug.

I wasn't arguing it is. I'm just saying it's not as trivial as you made
it sound.


> BTW, even back in the 1970's, people developing EEPROM systems would
> plug a special device into the board which would redirect the EEPROM
> access to some off-board RAM, or would debug using emulators. Maybe
> this technology has been forgotten :-)

Well, nowadays people use VMware, which is essentially a glorified
emulator. :) There are times when you have to test on the actual device,
though, when emulation is imperfect.


> >But in many cases, the source of a bad value is easy to find because
> >of its uniqueness (hmm, why does variable x have a value of 24576? oh
> >I know, search for 24576 in the code). Nulls, though, can occur in
> >many places, and in D they are implicit. There's no easy way to
> >search for that.
> 
> Come on. Every type in D has a default initializer. There's still
> nothing special about null.
> 
> Even if you got rid of all the nulls and instead use the null object
> pattern, you're not going to find it any easier to track it down,
> and you're in even worse shape because now it can fail and you may
> not even detect the failure, or may discover the error much, much
> further from the source of the bug.

If the null object remembers who created it (file + line), this would
short-circuit a lot of time-consuming detective work you'd have to do
otherwise. That was the main thrust behind my original post. I didn't
really find the null object pattern, as it is generally used (dummy
values for fields, no-ops for methods), particularly useful as a
programming technique. It is, after all, just the OO version of a
sentinel, and sentinels have been around long before OO was. But if the
null object can be made smarter -- remember which piece of code created
it, for example -- then it might begin to be useful.

Otherwise, I don't see much value in Andrei's proposal.


T

-- 
We've all heard that a million monkeys banging on a million typewriters
will eventually reproduce the entire works of Shakespeare.  Now, thanks
to the Internet, we know this is not true. -- Robert Wilensk