From: Austin Ziegler <halostatue@...>
Date: 2004-11-02T07:33:05+09:00
Subject: Re: Another scrach on head

On Tue, 2 Nov 2004 06:33:50 +0900, ara.t.howard@noaa.gov
<ara.t.howard@noaa.gov> wrote:
> On Tue, 2 Nov 2004, Austin Ziegler wrote:
>> 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:

Note: your code won't do what you expect, will it?

> 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

Shouldn't that be:

  def solar_elev_file=(value)
    @solar_elev_file =
      case value
      when String
	value
      when true
	1
      when false
	0
      when Fixnum
        raise ArgumentError unless [0, 1].include?(value)
	value
      else
        raise TypeError, "solar_elev_file <#{ value.class }> "
      end
  end

This way, your gen_command never needs to see true or false values.

> if obj.nil?
>   raise 'some error'
  elsif obj == false
>   dont_do_something
> else
>   something_else
> end

The issue I have with a BoolClass is that it's not clearly an
ancestor of TrueClass and FalseClass (although you'll find arguments
from 2002 that suggest that I think it should be; I was wrong), and
there are many possible values for String#to_bool to choose from:

  hai
  iie
  1
  0
  true
  false
  yes
  no
  da
  nyet
  ...

:)

> 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

Mmmm. I think that it's more common to encounter a nil variable
(e.g., unset) than one that is randomly false or true.

>   if obj = nil  # OOPS!
> same applies for true?
>   if obj = true # OOPS!

  if nil == obj
  if true == obj

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

I disagree on the commonality. I think that #nil? is a common enough
operation, but I personally rarely use explicit Boolean values.

-austin
-- 
Austin Ziegler * halostatue@gmail.com
               * Alternate: austin@halostatue.ca