On Mon, 2004-11-01 at 18:03, 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
> 
> 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

or, 

case conf['key'].class
   when TrueClass  : true
   when FalseClass : false
   when NilClass   : nil
   else            : Klass
end

--
Mohammad


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