From: Austin Ziegler <halostatue@...>
Date: 2005-05-09T08:14:56+09:00
Subject: Re: RCR 303: nil should accept missing methods and return nil

On 5/8/05, John Carter <john.carter@tait.co.nz> wrote:
> On Sat, 7 May 2005, Austin Ziegler wrote:
> > You may, however, be left with incorrect output.
> >  "\n#{@oid} 0 obj\n<</Type /Page /Parent #{@owner.oid} 0 R >>"
> > If @owner is nil, then using your proposal I will get:
> >  234 0 obj
> >  <</Type /Page /Parent 0 R >>
> Hmm. Interesting.
> Hard real, live, data.
> I like it.
> Let's look at it a bit more closely.

> How did the nil get into @owner? Would it have been picked up by -w?
> Was it placed there yourself in the meaning "uninitialised" or in the
> meaning "no thing here"? By what route did it arrive?

In this *particular* case, it is usually a case of forgotten
initialization -- but -w only helps so much. But my point was more
illustrative than anything else. This could have happened with another
line of code than I picked, perhaps from malformed user input that was
improperly guarded against. Without an exception on an attempt to call
a method on nil, it would be difficult to trace this.

> Given my new proposal of having an uninitialised vs nothing
> types of nil?

I think that the discussion in relation to relational databases is an
informative one here. Originally, Codd specified multiple types of
NULL -- for much the same reason you have. The SQL standard combined
these into a single NULL. In later life, though, Codd and his
successors have determined that NULL values in database tables are bad
and represent a bad logical table design.

We already have a problem where sometimes we need #nil_or_empty? I
don't want to add a case of #uninitialised_or_nil_or_empty?

-austin
-- 
Austin Ziegler * halostatue@gmail.com
               * Alternate: austin@halostatue.ca