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
···
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:
--
Austin Ziegler * halostatue@gmail.com
* Alternate: austin@halostatue.ca