Hi --

On Thu, 11 Aug 2005, John Carter wrote:

> On Wed, 10 Aug 2005, Austin Ziegler wrote:
>
>> On 8/10/05, BearItAll <bearitall / rassler.co.uk> wrote:
>>> On Wed, 10 Aug 2005 14:44:15 +0900, John Carter wrote:
>>>> class NilClass
>>>>    def empty?
>>>>      true
>>>>    end
>>>> end
>>>> if a.empty?
>>> I vote for this one because a good programmer is a lazy sod. Where ever
>>> you would end up doing a thing more than once, write it is such a way that
>>> you never have to type it again.
>> 
>> Just, please, don't do it in a library that you unleash on the rest of
>> the world. It changes the contract for +nil+, and I prefer that it
>> *not* respond to #empty?, because the concept isn't *quite* accurate.
>
> Well...
>
> I did say long and loud and tediously in the RCR 303 discussion that we there 
> are several meanings to nil and we need to change ruby to distinguish between 
> them.
>
> The original poster had a NoThing type of nil. Your fear arises from the 
> possibility of applying the empty? method to an Unitialized or NotApplicable 
> type of nil.

I would say that asking whether nil is empty is like asking whether 12
is empty: it just doesn't mean anything.  Even having it say "false"
suggests that "true" is possible.  In general, I don't think
non-container objects should be declaring themselves "empty".


David

-- 
David A. Black
dblack / wobblini.net