On 8/17/05, Trans <transfire / gmail.com> wrote:
> Austin, I'd like to see a _real_ example of where NilClass' suppossed
> contract of not responding to #empty? is going to cause a major
> malfunction. If anyone is depending on #empty? to throw an error on a
> errant nil result, they really need to reconsider their programming
> strategy to begin with.

1. It isn't a supposed contract. By default, Ruby does not offer #empty?
   on nil.
2. If an object does not respond to a message -- either through its
   methods or its ancestral methods -- an exception will be thrown.
3. Software that uses #empty? in duck typing often expects that invalid
   values won't respond to it but will, instead, throw an exception.
4. Most of the software that I've written in the last fourteen months
   rather depends on #3. That's because I do everything I can to make
   sure that the method is called with correct values; if it is not
   called with a correct value, then I expect that an error will be
   thrown.

This isn't a matter of needing to reconsider my programming strategy.
This is a matter of using the facilities which are available to me. It
gets worse if you accept Mr Carter's premise that +nil+ is better as an
"eater" object, because many things are NOT correct if a method is just
eaten and it is MORE correct to throw an exception than to produce
invalid data.

If you want something like this, use a new method. Make it clear. But
+nil+ isn't anything; therefore it can't be empty and it can't be
non-empty.

> Lastly, let me say that there is indeed a rasonable distinction
> between two types of nil, and only two types. The first is the
> non-object object. This is the typical use of Ruby's nil, it is a kind
> of filler, or dummy object, often removed as in Array#compact. The
> other type is a _nack_, a not-acknowledged object. Nack isn't a useful
> object in and of itself. It does nothing more then communicate a
> message that something is invalid or to be ignored. As such it would
> has no useful methods other then those to raise the error for which it
> is essentially a supression of. In fact the NackClass I designed was
> originally a subclass of Exception (now it uses delegation instead for
> unrelated reasons).

I disagree. The distinction between that which is +nil+ and that which
is +nack+ed merely adds complexity without adding significant meaning or
utility. Perl doesn't escape this in the least, with its "undef"
keyword.

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