From: ara.t.howard@...
Date: 2006-10-07T02:26:52+09:00
Subject: Re: nil being empty

On Sat, 7 Oct 2006, Trans wrote:

> That's the best example I have yet seen. Thanks for that Ara. Yet there's
> still a problem. Your expecting a NoMethodError on nil, just like I said.
> That's the thing, there's no other possible issue involved here. Now I'll
> grant James' concern that it can make some bugs harder to track down, but if
> that's our primary concern then I suggest we get back to static typing.
>
> Consider further, that ANY EXTENSION WHATSOEVER can have the same effect. If
> someone's class X defines #geegee and I add #geegee  to String, one can no
> long expect String to raise a NoMethodError on #geegee. So I argue that the
> bad form is not in using nil.empty? BUt in expecting such an error, and not
> addressing it properly.
>
>  hash_of_lists = Hash.new{|h,k| h[k] = new_list}
>  raise AProperError unless hash_of_lists[:key]
>  hash_of_lists[:key] << 42 if hash_of_lists[:key].empty?

good points.  i guess what i'm driving at is this:

the test of whether something is empty or not implies that it might be able to
contain something.  so, in my mind, a better question is show a code exampe
where having nil respond to empty? with true helps the code be more
readable/maintainable/correct/whatever.  for example

   x = nil

   if x.empty?
     # then what?
   end

see, it's the inverse of your problem.  one would have to do this for it to be
useful

   x = nil

   if x.empty?
     case x
       when Array
         ...
       when NilClass
         ...
     end
   end

because knowing it's empty doesn't really help you use - as you are correctly
pointing out in your comments.

so - to the op i guess - why would you do that in the first place and would it
ever really give you a gain over

   if x.nil? or x.empty?
     ...
   end

??

-a
-- 
in order to be effective truth must penetrate like an arrow - and that is
likely to hurt. -- wei wu wei