On Tue, 2 Nov 2004 10:14:00 +0900, ara.t.howard / noaa.gov
<ara.t.howard / noaa.gov> wrote:
> On Tue, 2 Nov 2004, Austin Ziegler wrote:
>> 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?" :)
> 
> ah yes - that bug is actually fixed in a bunch of similar code -
> in reality it has no effect since having 'solar_elev_file=0' in
> the command is the same as not having it, but it's a bug
> nonetheless... good catch for just reading email though!

:)

>> 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
> which, lol, fails for the same reason as my code ;-)

Actually, not at all. By using SolarElevFile, the value of
#solar_elev_file will either be +nil+ or an instance of
SolarElevFile. Thus, it uses Ruby's normal boolean test behaviour
and does exactly what it's supposed to...

> i __do__ like your AttributeClass approach though. i'd quickly
> have
> 
> BooleanAttributeClass < AttributeClass
> StringAttributeClass < AttributeClass
> FloatAttributeClass < AttributeClass
> 
> etc. essentially mappings of many ruby types to one idl type...
> food for thought.

Well, it's usable for that.

-austin
-- 
Austin Ziegler * halostatue / gmail.com
               * Alternate: austin / halostatue.ca
: as of this email, I have [ 5 ] Gmail invitations