ara.t.howard / noaa.gov wrote:
> 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
>

I see your point. And honestly, along those lines I think one could
made a good argument that nil shouldn't be a real object at all, just a
special value. But as things stand it is an object and there is some
precedence for things like #empty? Namely,

  nil.to_a
  nil.to_s

The core issue is really the dangers of extensions. Let's work on
mitigating those. If we can do that, then we woun't have to be so
concerned with unconventional polymorphisms.

T.