On Tue, 2 Nov 2004 08:03:50 +0900, ara.t.howard / noaa.gov
<ara.t.howard / noaa.gov> wrote:
> On Tue, 2 Nov 2004, Austin Ziegler wrote:
>> 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.
> i actually coded it that way up front and hated it. the reason is that the
> actual value set was lost. it made debugging really hard since i could not
> tell if
> 
> a) original input was bad
> b) i created bad bad input

Hmm. Alternatively:

  class SolarElevFile
    def initialize(value)
	# your normal check...
      @value = value
    end

    def to_s
      case @value
      when String
	",solar_elev_file='#{@value}'"
      when true
	",solar_elev_file=1"
      when false
	",solar_elev_file=0"
      when Fixnum
	",solar_elev_file=#{@value}"
      end
    end
  end

Also note that your original gen_command wouldn't work:
  def gen_command
    command = "%s,'%s','%s'" % [program, olsfile, flagfile]

    if solar_elev_file
      case solar_elev_file
      ...
      when FalseClass
	command << ",solar_elev_file=0"
      ...
      end
    end

This is because the "if solar_elev_file" test would fail if it were
false. Perhaps your test would have better been "unless
solar_elev_file.nil?" :)

Using the class, it would be:

  def solar_elev_file=(value)
    @solar_elev_file = SolarElevFile.new(value)
  end

  def solar_elev_file
    @solar_elev_file
  end

  ...

  def gen_command
    command = "%s,'%s','%s" % [ program, olsfile, flagfile ]

    ...
    command << solar_elev_file.to_s if solar_elev_file
    ...
  end

I think that there's a bit of OOness that could be applied to your
code here.

> yes - good point.
> 
> i think most people would agree that TrueClass and FalseClass and
> two sides of the same coin though?

Mmmm. As I said, I don't know that I agree anymore with that
position. They are inverse values of one another, but they aren't
necessarily descendants of the same class. More to the point, the
issue is more like:

  require 'uninheritable'

  class BooleanClass; end
  class TrueClass < BooleanClass; end
  true = TrueClass.new
  class FalseClass < BooleanClass; end
  false = FalseClass.new
  class BooleanClass
    extend Uninheritable
    undef_method :new
  end

The real issue becomes a matter of the value (or rather, what I view
as the lack thereof) of having to do the above. You don't want any
other instances of either TrueClass, or FalseClass -- and you don't
want an instance of BooleanClass, because it has no meaningful or
useful value. So you'd be introducing BooleanClass solely for the
use of true#ancestors and the like.

>> Mmmm. I think that it's more common to encounter a nil variable
>> (e.g., unset) than one that is randomly false or true.
> i'm running into the latter alot lately:
> 
> config = <<-yaml
>   key : ~
> yaml

...

Maybe that's something that can be changed with the way that YAML
handles truth values. I'm not sure.

>> I disagree on the commonality. I think that #nil? is a common
>> enough operation, but I personally rarely use explicit Boolean
>> values.
> think hashes:
> 
> h = {
> :key => false,
> }
> 
> i end up using #has_key? alot in these conditions... maybe i use hashes too
> much ;-)

I donno. Ruwiki uses hashes heavily :)

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