From: Ara.T.Howard@...
Date: 2004-11-02T08:03:50+09:00
Subject: Re: Another scrach on head

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

also, by keeping the actual values around i can use the ruby properties of
them.  for example, some of the attributes are Time objects - if i convert to
string up front i lost all Times.instance_methods and am left with only a
String (what idl needs).  so i made the choice to keep to original value for
each attribute (verified as begin correct) and convert only at the last
minute.  in fact i find this to be a general rule with input/ouput of any kind
while programming - never convert input up front unless required for
performance, always keep the 'raw' input and defer conversion

another very important reason, in this specific case, was that certain error
checking cannot be done untill all attributes have been set and i am
generating the command - for example attribute A may be require to be a String,
but only if attribute B is a bool (true? false?).  i could do some complex
dependancy tracking but it was easier to simply allow all attributes to be
idependantly correct when setting and to confirm the relationships when
generating the command...

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

yes - good point.

i think most people would agree that TrueClass and FalseClass and two sides of
the same coin though?

> 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

   conf = YAML::load config

   unless conf['key']
     if conf['key'] == false
       ...
     end
     if conf['key'].nil?
       ...
     end
   else
     ...
   end

eg.  both cases.  i think the above is just too heavy for ruby.  i'd really
like to see something better - maybe

   case conf['key'].truth
     when true
     when false
     when nil
   end

i dunno...  saying "if it is false and 'false' or it is false and 'nil'" is
just ...  heavy.

> 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 ;-)

anyway - i'm not hung up on it but do think it's a normal expectation to have
true? and false? when we have nil? and zero?.  after all, how common is zero?
?  (sheesh there a too many ? marks here!).  also, i really feel the
'asignment vs. comparison' argument is strong.

so now you know my two cents - for all that they are worth.  it's great that
we can complain about things like this instead of 'triple contruction upon
insert into the stl::map' or something horrible like that eh?  ;-)

cheers.

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