From: "T. Onoma" <transami@...>
Date: 2004-01-24T15:40:57+09:00
Subject: Re: [ANN] Ruby/Extensions v0.3 released

On Saturday 24 January 2004 04:44 am, Austin Ziegler wrote:
> I don't think that's what Gavin said at all. I don't particularly consider
> your additions to NilClass to be "acceptable." I certainly treat nil as a
> non-value, not an empty value. If I think that I might get a nil value, I
> *always* test for #nil?. It might be okay to have NilClass#to_s (or is it
> #to_str) return '' (nil-string), but I personally don't ever rely on the
> NilClass#to_a or NilClass#to_i behaviours.

how does one define acceptable? is it not enough that suggestions for such 
methods reoccur often on ruby-talk? or just that you "personally don't ever 
rely on" them? or for gavin, "that's an assumption I (almost) never want to 
make in my code." hence the indication of "approved" rather then 
"acceptable". moreover, i think your argument would be much more 
understandable if there were no precedence for such methods, but since to_a 
and to_i are already present, then to some extent such methods are already 
acceptable. but i may be assuming to much, and stand corrected if i've 
overread.

as to the use itself. these method provide a means to circumvent *having* to 
implement type and error checks when it is not important, that is, when 
"emptiness" is meant, much like default parameters allow us to circumvent 
*having* to supply method prameters. obviously it is not neccessary, but 
being able to drop a #to_f or #empty? call on a method or variable that may 
return nil when a float or array is typically expected can be very 
convenient, saving us extraneous 'if x != nil' clauses.

one may argue that using such methods goes against good coding practices. yet 
one of the things i like about ruby is that it lets me decide which 
--convenience vs. when proper coding practice, is of most importance for a 
given problem.

anyway, it dosen't much matter a great deal to me. I was just trying to get a 
feel for what "scope" of inclusion Ruby/Extentions was going to provide.

thanks,
T.