From: Trans <transfire@...>
Date: 2005-08-17T13:08:28+09:00
Subject: Re: NEWBIE QUESTION: pattern with nil

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.

But that aside, there are other ways to intgerate polymorphic
charateristices between conceptually distinct classes. RoR's #blank? is
an example, albiet a lousy one, both in how it is defined and it's
semantic value. A better one that I have used is #to_b (akin to but
more fluid then to_bool):

  class NilClass
    def to_b ; false ; end
  end

  class String
    def to_b ; !empty? ; end
  end

And so on for the other classes.

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).

T.