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. 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 - | 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 ===============================================================================