o.k. - bad example on my part. i'm more in favour of a bool? and false? test
(especially the false? test to tell difference from nil?). here's an example
of some real code i have:
def solar_elev_file= value
@solar_elev_file =
case value
when String, TrueClass, FalseClass
value
when Fixnum
unless [0,1].include? value
raise ArgumentError, "solar_elev_file <#{ value.inspect }>"
end
value
else
raise TypeError, "solar_elev_file <#{ value.class }>"
end
end
and then later...
def gen_command
command = "%s,'%s','%s'" % [program, olsfile, flagfile]
if solar_elev_file
case solar_elev_file
when String
command << ",solar_elev_file='#{ solar_elev_file }'"
when TrueClass
command << ",solar_elev_file=1"
when FalseClass
command << ",solar_elev_file=0"
when Fixnum
command << ",solar_elev_file=#{ solar_elev_file }"
end
end
...
in case you haven't guess this code generates a command to send to another
language... it sure is ugly!
i'd rather like to see something like
case value
when String, BoolClass
value
and be able to say things like
obj = obj.to_s if obj.bool? # map to 'true' or 'false' for idl
or even
if obj.nil?
raise 'some error'
elsif obj.false?
dont_do_something
else
something_else
end
or even
bool = str.to_bool
str = bool.to_str
or even
truth = obj.to_bool.to_str # map to 'true' or 'false' strings
i understand all the objections like 'why not obj == true' but this makes no
sense if one ever uses obj.nil? does it? after all, you could always do
if obj == nil
right? but we __like__ obj.nil? don't we? i think it's because you cannot do
this
if obj = nil # OOPS!
same applies for true?
if obj = true # OOPS!
of course i've done this many times
truth = (obj = true) # OOPS AGAIN!
these are hard bugs to find. if i had #true? i'd use it to prevent them:
truth = obj.true? or other_obj.false? # no bug here
so, in summary, i don't know what the hell i'm saying - just that, to me, it
seems that either:
- we have nil?, zero?, true?, false?, bool? and a more unified handling of
truth (TruthClass < BoolClass and FalseClass < BoolClass)
- we don't have any of it
because testing for nil and zero have got to be just as common/not-common as
testing for false instead of nil or, worse, just as common as accidentally
doing an assignment (=) vs. a comparison (==). to me that reason alone is
reason enough for true? and is better because, unlike compiler warnings,
cannot be ignored or turned off.
anyhow - i hope it's clear i'm just saying i'd like to see a unification of
truth handling in ruby and that true?, false?, bool? and friends would be a
natural __part__ of that unification but by no means the whole thing.
kind regards and sorry for bad examples!
-a
···
On Tue, 2 Nov 2004, Austin Ziegler wrote:
On Tue, 2 Nov 2004 05:47:18 +0900, Jim Weirich <jim@weirichhouse.org> wrote:
Ara.T.Howard@noaa.gov said:
now i use
if TrueClass === options['verbose']
@verbosity = 4
else
@verbosity = Integer options['verbose']
end
Hmmm ... why don't you use:
if options['verbose'] == true
...
See, that's why I'm not getting this. I don't see the value of:
if options['verbose'].true?
over
if options['verbose'] == true
The reality is that the implementations of #true? and #false? provided
so far essentially hide that test, making this pure magic. I certainly
don't test against true and false values often enough to warrant these
methods, whereas I do consistently test against nil values.
-
EMAIL :: Ara [dot] T [dot] Howard [at] noaa [dot] gov
PHONE :: 303.497.6469
When you do something, you should burn yourself completely, like a good
bonfire, leaving no trace of yourself. --Shunryu Suzuki
===============================================================================
